On Wed, Apr 26, 2023 at 04:57:04PM -0400, Rodrigo Vivi wrote:
> The goal is to allow for a snapshot capture to be taken at the time
> of the crash, while the print out can happen at a later time through
> the exposed devcoredump virtual device.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu
On Wed, Apr 26, 2023 at 04:57:03PM -0400, Rodrigo Vivi wrote:
> No functional change here. The goal is to have a clear split between
> the mapped portions of the CTB and the static information, so we can
> easily capture snapshots that will be used for later read out with
> the devcoredump infrastr
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a def
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: F
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, ha
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by a
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI changes,
1. end support for set caching ioctl [PA
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, ha
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by a
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: F
From: Fei Yang
This patch set was posted at
https://patchwork.freedesktop.org/series/116868/
Change title since the PTE patch was merged separately.
These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/
This series refactor the cache policy programming so that
Em 01/05/2023 16:24, Alex Deucher escreveu:
On Mon, May 1, 2023 at 2:58 PM André Almeida wrote:
I know that devcoredump is also used for this kind of information, but I believe
that using an IOCTL is better for interfacing Mesa + Linux rather than parsing
a file that its contents are subjected
The blanking calculation currently uses burst_clk_rate for calculating
the settings. Since it's possible to use this in non-burst mode, it's
possible that where won't be burst_clk_rate. Instead, cache the
clock rate configured from of samsung_dsim_set_pll and use it instead.
Signed-off-by: Adam F
In order to support variable DPHY timings, it's necessary
to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config
can be used to determine the nominal values for a given resolution
and refresh rate.
Signed-off-by: Adam Ford
---
drivers/gpu/drm/bridge/Kconfig | 1 +
1 file changed, 1
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel c
The DPHY timings are currently hard coded. Since the input
clock can be variable, the phy timings need to be variable
too. Add an additional variable to the driver data to enable
this feature to prevent breaking boards that don't support it.
The phy_mipi_dphy_get_default_config function configure
Make the pll-clock-frequency optional. If it's present, use it
to maintain backwards compatibility with existing hardware. If it
is absent, read clock rate of "sclk_mipi" to determine the rate.
Signed-off-by: Adam Ford
Tested-by: Chen-Yu Tsai
---
drivers/gpu/drm/bridge/samsung-dsim.c | 12 +++
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min
and max values for M and the frequency range for the VCO_out
calculator were incorrect. This information was contradicted in other
parts of the mini, nano and plus manuals. After reaching out to my
NXP Rep, when confronting him
From: Lucas Stach
Scale the blanking packet sizes to match the ratio between HS clock
and DPI interface clock. The controller seems to do internal scaling
to the number of active lanes, so we don't take those into account.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
Tested-by: Chen-Yu
This series fixes the blanking pack size and the PMS calculation. It then
adds support to allows the DSIM to dynamically DPHY clocks, and support
non-burst mode while allowing the removal of the hard-coded clock values
for the PLL for imx8m mini/nano/plus, and it allows the removal of the
burst-cl
On 5/1/2023 1:50 PM, Dmitry Baryshkov wrote:
On 01/05/2023 23:40, Kuogee Hsieh wrote:
On 4/28/2023 5:30 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test
On 2023-05-02 01:15:24, Dmitry Baryshkov wrote:
> On 02/05/2023 01:13, Marijn Suijten wrote:
> > On 2023-04-30 23:35:54, Dmitry Baryshkov wrote:
> >> dpu_rm_init() contains checks for block->id values. These were logical
> >> in the vendor driver, when one can not be sure which values were passed
>
On 02/05/2023 01:23, Marijn Suijten wrote:
On 2023-04-30 23:35:56, Dmitry Baryshkov wrote:
Move the check for lm->pingpong being not NONE from dpu_rm_init() to
dpu_lm_init(), following the change to dpu_hw_intf_init().
Signed-off-by: Dmitry Baryshkov
In some way I also suggested this change
On 2023-04-30 23:35:56, Dmitry Baryshkov wrote:
> Move the check for lm->pingpong being not NONE from dpu_rm_init() to
> dpu_lm_init(), following the change to dpu_hw_intf_init().
>
> Signed-off-by: Dmitry Baryshkov
In some way I also suggested this change in [1], but did not receive a
(N)ACK.
On 02/05/2023 01:17, Marijn Suijten wrote:
On 2023-04-30 23:35:55, Dmitry Baryshkov wrote:
On msm8998/sdm845 some LM blocks do not have corresponding PINGPONG
block. Currently the driver uses PINGPONG_MAX for such cases. Switch
that to use PINGPONG_NONE instead, which is more logical.
dpu_lm_c
On 2023-04-30 23:35:55, Dmitry Baryshkov wrote:
> On msm8998/sdm845 some LM blocks do not have corresponding PINGPONG
> block. Currently the driver uses PINGPONG_MAX for such cases. Switch
> that to use PINGPONG_NONE instead, which is more logical.
dpu_lm_cfg::pingpong still has a doc-comment stat
On 02/05/2023 01:13, Marijn Suijten wrote:
On 2023-04-30 23:35:54, Dmitry Baryshkov wrote:
dpu_rm_init() contains checks for block->id values. These were logical
in the vendor driver, when one can not be sure which values were passed
from DT. In the upstream driver this is not necessary: the cat
On 2023-04-30 23:35:54, Dmitry Baryshkov wrote:
> dpu_rm_init() contains checks for block->id values. These were logical
> in the vendor driver, when one can not be sure which values were passed
> from DT. In the upstream driver this is not necessary: the catalog is a
> part of the driver, we contr
On 2023-04-30 23:35:53, Dmitry Baryshkov wrote:
> Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
> the value is NULL, then the function will return 0 instead of a proper
> return code. Moreover dpu_hw_dsc_init() can not return NULL.
More specifically, it allows the init fu
On 02/05/2023 00:22, Abhinav Kumar wrote:
On 5/1/2023 1:45 PM, Dmitry Baryshkov wrote:
On 01/05/2023 22:58, Abhinav Kumar wrote:
On 4/30/2023 4:57 PM, Dmitry Baryshkov wrote:
There is no reason to split the dpu_encoder interface into separate
_init() and _setup() phases. Merge them into a
On 1.05.2023 21:40, Akhil P Oommen wrote:
> On Fri, Mar 31, 2023 at 01:25:20AM +0200, Konrad Dybcio wrote:
>> Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
>> but don't implement the associated GMUs. This is due to the fact that
>> the GMU directly pokes at RPMh. Sadly, th
On 5/1/2023 1:45 PM, Dmitry Baryshkov wrote:
On 01/05/2023 22:58, Abhinav Kumar wrote:
On 4/30/2023 4:57 PM, Dmitry Baryshkov wrote:
There is no reason to split the dpu_encoder interface into separate
_init() and _setup() phases. Merge them into a single function.
I think the reason for
On Mon, May 1, 2023 at 1:56 PM Dmitry Baryshkov
wrote:
>
> On 01/05/2023 23:44, Rob Clark wrote:
> > From: Rob Clark
> >
> > Fixes the following splat on a6xx gen2+ (a640, a650, a660 families),
> > a6xx gen1 has smaller GMU allocations so they fit under the default
> > 64K max segment size.
> >
>
On 01/05/2023 23:44, Rob Clark wrote:
From: Rob Clark
Fixes the following splat on a6xx gen2+ (a640, a650, a660 families),
a6xx gen1 has smaller GMU allocations so they fit under the default
64K max segment size.
[ cut here ]
DMA-API: msm_dpu ae01000.display-con
On 01/05/2023 23:40, Kuogee Hsieh wrote:
On 4/28/2023 5:30 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
What exactly was reported?
Signed-of
From: Rob Clark
Fixes the following splat on a6xx gen2+ (a640, a650, a660 families),
a6xx gen1 has smaller GMU allocations so they fit under the default
64K max segment size.
[ cut here ]
DMA-API: msm_dpu ae01000.display-controller: mapping sg segment longer than
d
On 01/05/2023 22:58, Abhinav Kumar wrote:
On 4/30/2023 4:57 PM, Dmitry Baryshkov wrote:
There is no reason to split the dpu_encoder interface into separate
_init() and _setup() phases. Merge them into a single function.
I think the reason for having this split was to pass a valid encoder to
On 4/28/2023 5:30 PM, Dmitry Baryshkov wrote:
On 29/04/2023 02:45, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Reported-by: kernel test robot
What exactly was reported?
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm
On 4/30/2023 4:57 PM, Dmitry Baryshkov wrote:
There is no reason to split the dpu_encoder interface into separate
_init() and _setup() phases. Merge them into a single function.
I think the reason for having this split was to pass a valid encoder to
the interface_modeset_init() and then do
On Fri, Mar 31, 2023 at 01:25:20AM +0200, Konrad Dybcio wrote:
> Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
> but don't implement the associated GMUs. This is due to the fact that
> the GMU directly pokes at RPMh. Sadly, this means we have to take care
> of enabling & scal
On Mon, May 1, 2023 at 2:58 PM André Almeida wrote:
>
> Add an interface to point out to userspace the guilty indirect buffer
> when a GPU reset happens, so the usermode driver can dump just the right
> IB for debug investigation.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/amdg
On Mon, May 1, 2023 at 2:58 PM André Almeida wrote:
>
> Currently UMD hasn't much information on what went wrong during a GPU reset.
> To
> help with that, this patch proposes a new IOCTL that can be used to query
> information about the resources that caused the hang.
If we went with the IOCTL,
On 5/1/2023 11:56 AM, Dmitry Baryshkov wrote:
On 01/05/2023 21:49, Abhinav Kumar wrote:
On 4/29/2023 2:25 PM, Dmitry Baryshkov wrote:
The driver doesn't support hsic/memcolor and pcc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
Changes since v2:
-
Add an interface to point out to userspace the guilty indirect buffer
when a GPU reset happens, so the usermode driver can dump just the right
IB for debug investigation.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
Currently UMD hasn't much information on what went wrong during a GPU reset. To
help with that, this patch proposes a new IOCTL that can be used to query
information about the resources that caused the hang.
The goal of this RFC is to gather feedback about this interface. The mesa part
can be foun
On 01/05/2023 21:49, Abhinav Kumar wrote:
On 4/29/2023 2:25 PM, Dmitry Baryshkov wrote:
The driver doesn't support hsic/memcolor and pcc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
Changes since v2:
- Fixed commit message to remove igc block mention.
Add myself as maintainer of the Samsung S6D7AA0 panel driver.
Signed-off-by: Artur Weber
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59a9a22a69fc..d1bc2f8b6e34 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6641,6 +6641,12 @@ S:
Initial driver for S6D7AA0-controlled panels. Currently, the following
panels are supported:
- S6D7AA0-LSL080AL02 (Samsung Galaxy Tab 3 8.0)
- S6D7AA0-LSL080AL03 (Samsung Galaxy Tab A 8.0 2015)
- S6D7AA0-LTL101AT01 (Samsung Galaxy Tab A 9.7 2015)
It should be possible to extend this driver to
This patchset adds initial support for Samsung S6D7AA0-based panels.
Currently, the following panels are supported:
- S6D7AA0-LSL080AL02 (Samsung Galaxy Tab 3 8.0)
- S6D7AA0-LSL080AL03 (Samsung Galaxy Tab A 8.0 2015)
- S6D7AA0-LTL101AT01 (Samsung Galaxy Tab A 9.7 2015)
Changed in v2:
- Added
Add bindings for the S6D7AA0 LCD panel controller, including the
S6D7AA0-LSL080AL02 panel used in the Samsung Galaxy Tab 3 8.0 family
of tablets, and the S6D7AA0-LSL080AL03 and S6D7AA0-LTL101AT01 panels
used in the Samsung Galaxy Tab A 8.0 and 9.7 2015.
Signed-off-by: Artur Weber
---
Changed in v
On 4/29/2023 2:25 PM, Dmitry Baryshkov wrote:
The driver doesn't support hsic/memcolor and pcc SSPP subblocks.
Drop corresponding definitions.
Signed-off-by: Dmitry Baryshkov
---
Changes since v2:
- Fixed commit message to remove igc block mention.
Changes since v1:
- Rebased on top of
On Mon, May 1, 2023 at 2:44 PM Felix Richter wrote:
>
> On 01.05.23 15:27, Alex Deucher wrote:
> > On Mon, May 1, 2023 at 3:20 AM Felix Richter
> > wrote:
> >> Hi,
> >>
> >> I am running into an issue with the integrated GPU of the Ryzen 9 7950X.
> >> It seems to be a regression from kernel ver
From: Rob Clark
Also store the override strings in drm_file so that fdinfo can display
them. We still need to keep our original copy as we could need these
override strings after the device file has been closed and drm_file
freed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno
From: Rob Clark
These are useful in particular for VM scenarios where the process which
has opened to drm device file is just a proxy for the real user in a VM
guest.
v2: doc cleanups
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 10 ++
drivers/gpu/drm/drm_file.
From: Rob Clark
The restriction about no whitespace, etc, really only applies to the
usage of strings in keys. Values can contain anything (other than
newline).
Signed-off-by: Rob Clark
Acked-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 27 ++-
1 fil
From: Rob Clark
Use the new helper to export stats about memory usage.
v2: Drop unintended hunk
v3: Rebase
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 15 +++
2 files changed, 17 insertions(+)
diff
From: Rob Clark
Add support to dump GEM stats to fdinfo.
v2: Fix typos, change size units to match docs, use div_u64
v3: Do it in core
v4: more kerneldoc
v5: doc fixes
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
Documentation/gpu/drm-usage-stats.rst | 5
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
From: Rob Clark
Now that we have a common helper, use it.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
drivers/gpu/drm/msm/msm_gpu.c | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_dr
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats. This also ensures consistent behavior
across drivers for standardised fields.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
From: Rob Clark
Fix a couple missing ':'s.
Signed-off-by: Rob Clark
Reviewed-by: Rodrigo Vivi
---
Documentation/gpu/drm-usage-stats.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index
From: Rob Clark
For errors after msm_submitqueue_get(), we need to drop the submitqueue
reference. Additionally after get_unused_fd() we need to drop the fd.
The ordering for dropping the queue lock and put_unused_fd() is not
important, so just move this all into out_post_unlock.
v2: Only drop
On Fri, Apr 28, 2023 at 4:05 AM Tvrtko Ursulin
wrote:
>
>
> On 27/04/2023 18:53, Rob Clark wrote:
> > From: Rob Clark
> >
> > These are useful in particular for VM scenarios where the process which
> > has opened to drm device file is just a proxy for the real user in a VM
> > guest.
> >
> > Sign
From: Rob Clark
For errors after msm_submitqueue_get(), we need to drop the submitqueue
reference. Additionally after get_unused_fd() we need to drop the fd.
The ordering for dropping the queue lock and put_unused_fd() is not
important, so just move this all into out_post_unlock.
Reported-by: p
On Tue, 18 Apr 2023 10:08:21 +0200
Paul Cercueil wrote:
> Hi Jonathan,
>
> Le dimanche 16 avril 2023 à 15:24 +0100, Jonathan Cameron a écrit :
> > On Mon, 3 Apr 2023 17:47:52 +0200
> > Paul Cercueil wrote:
> >
> > > The buffer-dma code was using two queues, incoming and outgoing, to
> > > m
On 4/6/23 19:06, Dmitry Osipenko wrote:
> Change locking policy of mmap() callback, making exporters responsible
> for handling dma-buf reservation locking. Previous locking policy stated
> that dma-buf is locked for both importers and exporters by the dma-buf
> core, which caused a deadlock proble
On 4/16/23 14:52, Dmitry Osipenko wrote:
> We have multiple Vulkan context types that are awaiting for the addition
> of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
>
> 1. Venus context
> 2. Native contexts (virtio-freedreno, virtio-intel, virtio-amdgpu)
>
> Mesa core supp
On 4/16/23 14:52, Dmitry Osipenko wrote:
> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
> support is needed by native context VirtIO-GPU Mesa drivers, it also will
> be used by Venus and Virgl contexts.
>
> Reviewed-by; Emil Velikov
> Signed-off-by: Dmitry Osipenko
> ---
>
From: Arnd Bergmann
A global function without a header prototype has made it into
linux-next during the merge window:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6339:6: error: no
previous prototype for 'amdgpu_dm_connector_funcs_force'
[-Werror=missing-prototypes]
Mark the fu
Maxime, Jernej, I was trying to understand why pll-video0 is not updated
and I tracked down the culprit to ccu_nkm.c.
On 2023-04-23 at 15:24:33 +0200, Frank Oltmanns wrote:
> On 2023-04-18 at 09:40:01 +0200, Roman Beranek wrote:
>> According to Allwinner's BSP code, in DSI mode, TCON0 clock need
On Mon, May 1, 2023 at 3:20 AM Felix Richter wrote:
>
> Hi,
>
> I am running into an issue with the integrated GPU of the Ryzen 9 7950X. It
> seems to be a regression from kernel version 6.1 to 6.2.
> The bug materializes in from of my monitor blinking, meaning it turns full
> white shortly. Thi
On 1.05.2023 14:39, Dmitry Baryshkov wrote:
> On 01/05/2023 15:37, Konrad Dybcio wrote:
>>
>>
>> On 1.05.2023 03:12, Dmitry Baryshkov wrote:
>>> If the dispcc uses CLK_OPS_PARENT_ENABLE (e.g. on QCM2290), CCF can try
>>> enabling VCO before the rate has been programmed. This can cause clock
>>>
On 01/05/2023 15:37, Konrad Dybcio wrote:
On 1.05.2023 03:12, Dmitry Baryshkov wrote:
If the dispcc uses CLK_OPS_PARENT_ENABLE (e.g. on QCM2290), CCF can try
enabling VCO before the rate has been programmed. This can cause clock
lockups and/or other boot issues. Program the VCO to the minimal
On 1.05.2023 03:12, Dmitry Baryshkov wrote:
> If the dispcc uses CLK_OPS_PARENT_ENABLE (e.g. on QCM2290), CCF can try
> enabling VCO before the rate has been programmed. This can cause clock
> lockups and/or other boot issues. Program the VCO to the minimal PLL
> rate if the read rate is 0 Hz.
>
Hi
I've not had any issues since using this, but I imagine most people
won't know how to set swiotlb=dynamic if they start seeing this (when
it lands)
Any clue as to why this broke last cycle?
Thanks
Mike
On Fri, 28 Apr 2023 at 10:07, Petr Tesařík wrote:
>
> On Fri, 28 Apr 2023 09:53:38 +0100
From: Ofir Bitton
Due to missing indication of address decode source (LBW/HBW bus),
we should always try and fetch extended information.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 14 ++
1 file cha
From: Koby Elbaz
Use a straight forward approach to get a conditional result.
Signed-off-by: Koby Elbaz
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/accel/hab
From: Tomer Tayar
Currently the debugfs root folder and files for a device are created at
an early step, before the device initialization and before the char
device and sysfs files are exposed to user.
As there is no real reason not to do it together with the device
creation, postpone it to be do
From: Koby Elbaz
Currently, we rely on COMMS protocol's ack to verify that WFE command
has been acknowledged by the FW. However, this does not guarantee that
the device status has been updated.
Although unlikely, this could trigger a race since the driver expects
the device to be halted at that s
From: Dafna Hirschfeld
For some reason the last possible tpc interrupt cause in
gaudi2_tpc_interrupts_cause is missing from the code.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 3 ++-
1 file changed, 2 in
From: Ofir Bitton
Currently upon a heartbeat failure, we don't know if the failure
is due to firmware hang or due to a bad PCI link. Hence, we
are reading a PCI config space register with a known value (vendor ID)
so we will know which of the two possibilities caused the heartbeat
failure.
Signe
Hi,
I am running into an issue with the integrated GPU of the Ryzen 9 7950X. It
seems to be a regression from kernel version 6.1 to 6.2.
The bug materializes in from of my monitor blinking, meaning it turns full
white shortly. This happens very often so that the system becomes unpleasant to
us
Smatch reports:
drivers/gpu/drm/sun4i/sun4i_tcon.c:805 sun4i_tcon_init_clocks() warn:
'tcon->clk' from clk_prepare_enable() not released on lines: 792,801.
In the function sun4i_tcon_init_clocks(), tcon->clk and tcon->sclk0 are
not disabled in the error handling, which affects the release of
these
On 28/04/2023 18:02, Jianhua Lu wrote:
> The kinetic,ktz8866 is a I2C driver, so add the missing reg property.
> And update example to make it clear.
>
> Signed-off-by: Jianhua Lu
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
87 matches
Mail list logo
