在 2022/5/30 上午11:10, Haowen Bai 写道:
> The fan->base is dereferencing before null checking, so move
> it after checking.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Prevent a kconfig warning when MMU is not enabled by making
DRM_HISI_HIBMC depend on MMU.
WARNING: unmet direct dependencies detected for DRM_TTM
Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
Selected by [m]:
- DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m]
- DRM_HISI_HIBMC
On (22/05/30 16:55), Christian König wrote:
> Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
> > [SNIP]
> > So the `lock` should have at least same lifespan as the DMA fence
> > that borrows it, which is impossible to guarantee in our case.
>
> Nope, that's not correct. The lock should have at
在 2022/5/31 上午8:36, Abhinav Kumar 写道:
>
>
> On 5/30/2022 12:33 AM, Haowen Bai wrote:
>> The ctx->hw is dereferencing before null checking, so move
>> it after checking.
>>
>> Signed-off-by: Haowen Bai
>
> Agree with Dmitry's comment. Adjust the patch subject to a different one
> otherwise PW
在 2022/5/30 下午3:33, Haowen Bai 写道:
> The ctx->hw is dereferencing before null checking, so move
> it after checking.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
On 5/30/2022 12:33 AM, Haowen Bai wrote:
The ctx->hw is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
Agree with Dmitry's comment. Adjust the patch subject to a different one
otherwise PW thinks they are same patches.
Reviewed-by: Abhinav
On Mon, 30 May 2022 at 05:20, Haowen Bai wrote:
>
> The phys_enc->wb_idx is dereferencing before null checking, so move
> it after checking.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
A nit: patchwork thinks that two patches from the same author with the
same subject are two versions of the same patch. In future, could you
please send such patches with distinct names? No need to send v2 now
unless review shows other issues with the patches.
On Mon, 30 May 2022 at 10:33, Haowen
The pull request you sent on Mon, 30 May 2022 21:44:08 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/for-5.19/fbdev-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8ab2afa23bd197df47819a87f0265c0ac95c5b6a
Thank you!
--
The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c:
Linux 5.18-rc7 (2022-05-15 18:08:58 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
tags/for-5.19/fbdev-1
for you to fetch changes up to
On Mon, May 30, 2022 at 10:20 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.05.22 um 17:41 schrieb Rob Clark:
> > On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
> >>
> >> On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> >>>
> >>> On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> >>>
Hi
Am 30.05.22 um 17:41 schrieb Rob Clark:
On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
Hi
Am 29.05.22 um 18:29 schrieb Rob Clark:
From: Rob Clark
If a GEM object is
On 26/05/2022 09:33, Tvrtko Ursulin wrote:
On 26/05/2022 09:10, Matthew Auld wrote:
On 26/05/2022 08:58, Tvrtko Ursulin wrote:
On 25/05/2022 19:43, Matthew Auld wrote:
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add
On Mon, May 30, 2022 at 03:35:28PM +0200, Arnd Bergmann wrote:
> The annotations for edid are completely correct and necessary. However
> other driver authors just slap __packed annotations on any structure
> even if the layout is not fixed at all like:
>
> struct my_driver_priv {
>struct
On Mon, May 30, 2022 at 02:43:45PM +0200, Arnd Bergmann wrote:
> Overall I'm not that worried because the only machines running OABI
> kernels would be on really old hardware that runs a limited set of
> driver code.
... and from what I remember, none of them care about EDID anyway.
--
RMK's
On Mon, May 30, 2022 at 12:33:17PM +0300, Jani Nikula wrote:
> On Mon, 30 May 2022, Jani Nikula wrote:
> > On Sat, 28 May 2022, Linus Torvalds wrote:
> >> On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote:
> >>>
> >>> It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this
>
Hi Maxime,
On Mon, May 30, 2022 at 03:11:58PM +0200, Maxime Ripard wrote:
>
> Hi,
>
> On Mon, May 30, 2022 at 12:20:17PM +0200, José Expósito wrote:
> > Test the conversion from XRGB to RGB332.
> >
> > What is tested?
> >
> > - Different values for the X in XRGB to make sure it is
Add DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode
panel, which can be found on some Xiaomi Poco F1 phones. The panel's
backlight is managed through QCOM WLED driver.
Signed-off-by: Joel Selvaraj
Reviewed-by: Sam Ravnborg
---
Changes in v3: (Mostly Linus Walleij's Suggestions)
Add bindings for the EBBG FT8719 6.18" 2246x1080 DSI video mode panel,
which can be found on some Xiaomi Poco F1 phones. The backlight is
managed through the QCOM WLED driver.
Signed-off-by: Joel Selvaraj
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
---
Changes in v2: (Krzysztof
Add a prefix for EBBG. They manufacture displays which are used in some
Xiaomi phones, but I could not find much details about the company.
Signed-off-by: Joel Selvaraj
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2
Add bindings and DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI
video mode panel, which can be found on some Xiaomi Poco F1 phones.
The panel's backlight is managed through QCOM WLED driver.
The driver is built using linux-mdss-dsi-panel-driver-generator[1], and
additionally support for
On (22/05/30 16:55), Christian König wrote:
>
> If you just want to create a single dma_fence which is also only bound to a
> single context you can embed the lock into the fence without much problem.
>
> See how the dma_fence_array does that for example:
>
On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
>
> On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> >
> > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi
> > >
> > > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > > From: Rob Clark
> > > >
> > > > If a GEM
Hi Christian,
On (22/05/30 16:55), Christian König wrote:
> Hi Sergey,
>
> I'm removing most of the mail because you have a very fundamental
> misunderstanding about what this dma_fence lock is all about.
Happy to learn.
> Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
> > [SNIP]
> > So the
Use the new helper to improve the debug capabilities.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index
The bridge chip has an enable gpio which of course can enable/disable
the bridge. Most the time this gpio is connected directly to the host
but sometimes it is connected to a reset controller chip and the host
controlls the reset controller chip instead. This commit adds the
support to handle
The bridge device can now also be enabled/disabled by an external reset
controller. So the device now supports either enable/disable by simple
GPIO or by an Reset-Controller.
Signed-off-by: Marco Felsch
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml| 6 ++
1 file changed,
No functional change. Just reuse the already existing val variable to
setup the register. This is in preparation for adding the new feature to
reverse the CHA/CHB lane orders. Without this change this call gets very
unreadable.
Signed-off-by: Marco Felsch
---
Hi,
the purpose of this small series is to enable the support for the reverse
lane feature and to add support for reset controllers which can drive
the enable pin.
Regards,
Marco
Marco Felsch (6):
drm/bridge: ti-sn65dsi83: make lvds lane register setup more readable
dt-bindings:
The chip can swap the LVDS channel A/B data lanes e.g. to improve the
layout characteristic. This commit adds the feature so the system
integrator can specify it within the device-tree.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 64 +++
1
The TI converter chip can swap the LVDS data lanes in a pre-defined
manner. This can be useful to improve the layout characteristic.
Signed-off-by: Marco Felsch
---
.../bindings/display/bridge/ti,sn65dsi83.yaml | 58 ++-
1 file changed, 56 insertions(+), 2 deletions(-)
diff
Hi Sergey,
I'm removing most of the mail because you have a very fundamental
misunderstanding about what this dma_fence lock is all about.
Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
[SNIP]
So the `lock` should have at least same lifespan as the DMA fence
that borrows it, which is
On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
>
> On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > From: Rob Clark
> > >
> > > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > > mmap'd
Hi Sasha,
On 5/30/22 8:49 AM, Sasha Levin wrote:
> From: Samuel Holland
>
> [ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
>
> D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
> While there are some register changes, the part of the TCON TV supported
> by
On Mon, May 30, 2022 at 7:16 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.05.22 um 15:47 schrieb Rob Clark:
> > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 29.05.22 um 18:29 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> If a GEM object is
On Mon, May 30, 2022 at 4:08 PM Jani Nikula wrote:
> On Mon, 30 May 2022, Arnd Bergmann wrote:
> > struct my_driver_priv {
> >struct device dev;
> >u8 causes_misalignment;
> >spinlock_t lock;
> >atomic_t counter;
> > } __packed; /* this annotation is harmful
RFC
I don't have a good name for this yet and I did not spend
any time on documentataion (for that reason)
We create fences (out fences) as part of operations execution, which
are short-lived objects, we want to release all memory after operation
execution is completed or
Hi
Am 30.05.22 um 15:47 schrieb Rob Clark:
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
Hi
Am 29.05.22 um 18:29 schrieb Rob Clark:
From: Rob Clark
If a GEM object is allocated, and then exported as a dma-buf fd which is
mmap'd before or without the GEM buffer being directly
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
On Mon, 30 May 2022, Arnd Bergmann wrote:
> On Mon, May 30, 2022 at 3:10 PM Jani Nikula wrote:
>> >
>> > I think in general, most __packed annotations we have in the kernel are
>> > completely pointless because they do not change the structure layout on
>> > any architecture but instead just
The kernel test robot reports a compile warning due the ssd130x_spi_table
variable being defined but not used. This happen when ssd130x-spi driver
is built-in instead of being built as a module, i.e:
CC drivers/gpu/drm/solomon/ssd130x-spi.o
AR drivers/base/firmware_loader/built-in.a
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
On 5/30/22 16:41, Christian König wrote:
> Hi Dmitry,
>
> Am 30.05.22 um 15:26 schrieb Dmitry Osipenko:
>> Hello Christian,
>>
>> On 5/30/22 09:50, Christian König wrote:
>>> Hi Dmitry,
>>>
>>> First of all please separate out this patch from the rest of the series,
>>> since this is a complex
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
Hi Dmitry,
Am 30.05.22 um 15:26 schrieb Dmitry Osipenko:
Hello Christian,
On 5/30/22 09:50, Christian König wrote:
Hi Dmitry,
First of all please separate out this patch from the rest of the series,
since this is a complex separate structural change.
I assume all the patches will go via the
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 29.05.22 um 18:29 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > mmap'd before or without the GEM buffer being directly mmap'd, the
> > vma_node
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
Hi Maxime,
пн, 30 мая 2022 г. в 16:22, Maxime Ripard :
>
> Hi Roman,
>
> On Wed, May 25, 2022 at 11:54:45AM +, Roman Stratiienko wrote:
> > By this commit 2 related issues are solved:
> >
> > Issue #1. Corruption in blend route/enable register:
> >
> > Register corruption happens after
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Zack Rusin
[ Upstream commit 8bb75aeb58bd688d70827ae179bd3da57b6d975b ]
The kms code wasn't validating the modifiers and was letting through
unsupported formats. rgb8 was never properly supported and has no
matching svga screen target format so remove it.
This fixes format/modifier
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork:
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Sathishkumar S
[ Upstream commit cdf4c8ec39872a61a58d62f19b4db80f0f7bc586 ]
smartshift apu and dgpu power boost are reported as percentage
with respect to their power limits. adjust the units of power before
calculating the percentage of boost.
Signed-off-by: Sathishkumar S
Reviewed-by:
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing
From: Alex Deucher
[ Upstream commit b95b5391684b39695887afb4a13cccee7820f5d6 ]
Memory allocations should be done in sw_init. hw_init should
just be hardware programming needed to initialize the IP block.
This is how most other IP blocks work. Move the GPU memory
allocations from psp hw_init
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork:
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0,
From: Hans de Goede
[ Upstream commit 4b9caaa0281972ca5ea4e1cdac2e12b9df1ae00b ]
Lockdep complains about the smu->message_lock mutex being used before
it is initialized through the following call path:
amdgpu_device_init()
amdgpu_dpm_mode2_reset()
smu_mode2_reset()
From: Sathishkumar S
[ Upstream commit cdf4c8ec39872a61a58d62f19b4db80f0f7bc586 ]
smartshift apu and dgpu power boost are reported as percentage
with respect to their power limits. adjust the units of power before
calculating the percentage of boost.
Signed-off-by: Sathishkumar S
Reviewed-by:
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo
From: Thierry Reding
[ Upstream commit cb7e1abc2c73633e1eefa168ab2dad6e838899c9 ]
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR-
encoded error code and the cleanup code would try to free that memory,
which obviously would fail.
Zero out that pointer after extracting
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
From: Haohui Mai
[ Upstream commit 7dba6e838e741caadcf27ef717b6dcb561e77f89 ]
This patch fixes the issue where the driver miscomputes the 64-bit
values of the wptr of the SDMA doorbell when initializing the
hardware. SDMA engines v4 and later on have full 64-bit registers for
wptr thus they
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
From: Saaem Rizvi
[ Upstream commit 5d5af34072c8b11f60960c3bea57ff9de5877791 ]
[WHY]
Z10 is should not be enabled by default on DCN31.
[HOW]
Using DC debug flags to disable Z10 by default on DCN31.
Reviewed-by: Eric Yang
Acked-by: Pavle Kotarac
Signed-off-by: Saaem Rizvi
Signed-off-by:
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing
From: Alex Deucher
[ Upstream commit b95b5391684b39695887afb4a13cccee7820f5d6 ]
Memory allocations should be done in sw_init. hw_init should
just be hardware programming needed to initialize the IP block.
This is how most other IP blocks work. Move the GPU memory
allocations from psp hw_init
From: Thierry Reding
[ Upstream commit cb7e1abc2c73633e1eefa168ab2dad6e838899c9 ]
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR-
encoded error code and the cleanup code would try to free that memory,
which obviously would fail.
Zero out that pointer after extracting
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork:
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test
From: Mukul Joshi
[ Upstream commit b179fc28d521379ba7e0a38eec1a4c722e7ea634 ]
[ 168.544078] ==
[ 168.550309] WARNING: possible circular locking dependency detected
[ 168.556523] 5.16.0-kfd-fkuehlin #148 Tainted: GE
[
1 - 100 of 168 matches
Mail list logo
