On Fri, Mar 05, 2021 at 06:39:22PM +, Emil Velikov wrote:
> From: Emil Velikov
>
> The Hantro G1 IRQ and reset handling it pretty standard. I was this
> close to duplicating it, yet again, before reconsidering and refactoring
> it to a separate file.
>
> Cc: Ezequiel Garcia
> Cc: Philipp Za
Hi Emil,
On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> From: Emil Velikov
>
> The current imx8 code does not use the jpeg encoder. Remove the
> unnecessary include.
>
> Cc: Ezequiel Garcia
> Cc: Philipp Zabel
> Cc: linux-me...@vger.kernel.org
> Cc: linux-rockc...@lists.infra
Hi,
On 2021-02-05 17:38, Sai Prakash Ranjan wrote:
On 2021-02-04 03:16, Will Deacon wrote:
On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
On 2021-02-01 23:50, Jordan Crouse wrote:
> On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > On Mon, Feb 1, 2021 at 3:16
Currently we see only the MAX FRL BW from PCON before going for FRL.
Also add the check if source control mode is supported by the
PCON, before starting configuring PCON for FRL training.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
1 file changed, 2 inserti
Remove code for resetting frl related members from intel_disable_dp, as
this is not applicable for older platforms.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/disp
Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.
This patch:
-Add register masks for Sequential and Normal FRL training options.
-Fixes the dr
Patch1: Tweaks the drm_helpers for PCON configuration.
Patch2: Removes unwanted code not applicable for older platforms.
Patch3: Fixes condition for starting FRL link training.
rev3: Patch-1 from rev2 [Read PCON DSC ENC caps only for DPCD
rev >= 1.4] is dropped as it mixes DPCD and DP revisions.
As I realized, this patch is mixing DPCD rev and DP version, need an
appropriate check instead.
As for the gitlab issue
https://gitlab.freedesktop.org/drm/intel/-/issues/2868 this seems to be
not due to a DPCD register not defined for an older sink.
The DPCD read in that case should have bee
On Mon, Mar 8, 2021 at 4:36 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
> verifies that the BO size can fit the FB size by calculating the minimum
> expected size of each plane.
>
> The bug was caught using igt-gpu-tools tes
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in functi
Am 2021-03-08 um 3:45 p.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but
On Tuesday, 9 March 2021 6:44:41 AM AEDT Ralph Campbell wrote:
>
> On 3/3/21 10:16 PM, Alistair Popple wrote:
> > Some devices require exclusive write access to shared virtual
> > memory (SVM) ranges to perform atomic operations on that memory. This
> > requires CPU page tables to be updated to de
On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> On Wed, 3 Mar 2021 12:44:33 -0800
> "Navare, Manasi" wrote:
>
> > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > On Tue, 2 Mar 2021 12:41:32 -0800
> > > Manasi Navare wrote:
> > >
> > > > In case of a mo
On Tuesday, 9 March 2021 5:58:12 AM AEDT Ralph Campbell wrote:
>
> On 3/3/21 10:16 PM, Alistair Popple wrote:
> > Migration is currently implemented as a mode of operation for
> > try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
> > or in the case of splitting a huge anonym
On Sun, 07 Mar 2021 19:28:29 +, Paul Cercueil wrote:
> The NT39016 panel is a fun beast, even though the documentation states
> that the CS line is active-low, it will work just fine if the CS line is
> configured as active-high, but it won't work if the CS line is forced
> low or forced high.
The nomination period for the 2021 X.Org Foundation Board of Directors
Election closed yesterday and the election is rapidly approaching. We
currently only see membership renewals for 59 people.
If you have not renewed your membership please do so by Thursday, Mar 11
at https://members.x.org.
https://bugzilla.kernel.org/show_bug.cgi?id=212107
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Sun, Mar 7, 2021 at 10:14 PM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1600:40-45: WARNING: conversion
> to bool not needed here.
>
> ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1598:40-45: WARNING: conversion
> to bool not needed
On Sun, Mar 7, 2021 at 10:00 PM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:561:34-39: WARNING:
> conversion to bool not needed here.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
This patch was already ap
https://bugzilla.kernel.org/show_bug.cgi?id=211033
--- Comment #18 from Alex Deucher (alexdeuc...@gmail.com) ---
The original issue reported here was fixed. If you are having other issues,
please open new bugs.
--
You may reply to this email to add a comment.
You are receiving this mail becaus
Applied. Thanks!
Alex
On Sat, Mar 6, 2021 at 6:05 AM wrote:
>
> From: Zhang Yunkai
>
> 'dce110_resource.h' included in 'dcn21_resource.c' is duplicated.
> 'hw_gpio.h' included in 'hw_factory_dce110.c' is duplicated.
>
> Signed-off-by: Zhang Yunkai
> ---
> drivers/gpu/drm/amd/display/dc/dcn21
Applied. Thanks!
Alex
On Sat, Mar 6, 2021 at 5:48 AM wrote:
>
> From: Zhang Yunkai
>
> 'drm/drm_hdcp.h' included in 'amdgpu_dm.c' is duplicated.
> It is also included in the 79th line.
>
> Signed-off-by: Zhang Yunkai
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> 1 file c
From: Mark Yacoub
To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Tes
On Thu, Mar 4, 2021 at 2:15 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> To initialize the framebuffer, use drm_gem_fb_init_with_funcs which
> verifies that the BO size can fit the FB size by calculating the minimum
> expected size of each plane.
>
> The bug was caught using igt-gpu-tools test
Applied. Thanks!
Alex
On Thu, Mar 4, 2021 at 11:02 PM Quan, Evan wrote:
>
> [AMD Public Use]
>
> Thanks. Reviewed-by: Evan Quan
>
> -Original Message-
> From: Jia-Ju Bai
> Sent: Friday, March 5, 2021 11:54 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; airl...@linux.ie; dan...@f
vmwgfx has really ugly implemention of an interruptible lock trying
to match rw sem semantics. By adding a small bit of code implementing
down_write_interruptible to rwsem which already supported
down_read_interruptible we can completely remove all of the custom
code from vmwgfx.
Cc: Peter Zijlstr
vmwgfx used a custom locking code to support semantics of a
interruptible rwsem. Now with down_(read|write)_interruptible
implemented in the rwsem we can completely remove the custom
locking code. It also allows us to remove the hacks we needed
to support proper waits for write resources before
hib
Add an interruptible version of down_write. It's the other
side of the already implemented down_read_interruptible.
It allows drivers which used custom locking code to
support interruptible rw semaphores to switch over
to rwsem.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ker..
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/
Hi Parshuram,
On Tue, Mar 02, 2021 at 12:53:50PM +, Parshuram Raju Thombare wrote:
> Hi Laurent,
>
> >>> Is this a property of the hardware, that is, are there multiple versions
> >>> of this IP core covered by the same compatible string that support HDCP
> >>> 1.4 only, DHCP 2.2 only or both
On Mon, Mar 8, 2021 at 9:12 PM Christian König
wrote:
> Am 08.03.21 um 21:02 schrieb Felix Kuehling:
> > Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
> > I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid
> > it, because it is only really needed for a small number of AMD
On Thu, 04 Mar 2021 14:51:32 +0530, Jagan Teki wrote:
> ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
>
> It has a flexible configuration of MIPI DSI signal input and
> produces RGB565, RGB666, RGB888 output format.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki
> ---
> C
Am 08.03.21 um 21:02 schrieb Felix Kuehling:
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
The driver build should work without IOM
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
> On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
>> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
>>> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling
>>> wrote:
The driver build should work without IOMMUv2. In amdkfd/Makefile, we
>>>
On 3/3/21 10:16 PM, Alistair Popple wrote:
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this intro
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolutio
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
>
> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
> > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling
> > wrote:
> >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
> >> have this condition:
> >>
> >> ifneq ($(CONFIG_AM
On Mon, Mar 1, 2021 at 5:25 AM Christian König
wrote:
>
>
>
> Am 01.03.21 um 11:04 schrieb Daniel Vetter:
> > On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann
> > wrote:
> >> (cc'ing amd devs)
> >>
> >> Hi
> >>
> >> Am 28.02.21 um 17:10 schrieb Pavel Turinský:
> >>> The checks were removed in c
https://bugzilla.kernel.org/show_bug.cgi?id=212137
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Should be fixed with this patch:
https://patchwork.freedesktop.org/patch/423250/
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
>> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
>> have this condition:
>>
>> ifneq ($(CONFIG_AMD_IOMMU_V2),)
>> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
>> endif
>>
>
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
>
> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
> have this condition:
>
> ifneq ($(CONFIG_AMD_IOMMU_V2),)
> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
> endif
>
> In amdkfd/kfd_iommu.h we define inline stubs of the func
On Tue, 02 Mar 2021 17:24:01 +0100, Hans Verkuil wrote:
> The cec clock is required as well in order to support HDMI CEC,
> document this.
>
> Signed-off-by: Hans Verkuil
> ---
> Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletion
On 3/3/21 10:16 PM, Alistair Popple wrote:
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the
On 3/3/21 10:16 PM, Alistair Popple wrote:
The behaviour of try_to_unmap_one() is difficult to follow because it
performs different operations based on a fairly large set of flags used
in different combinations.
TTU_MUNLOCK is one such flag. However it is exclusively used by
try_to_munlock() w
On 3/3/21 10:16 PM, Alistair Popple wrote:
Both migration and device private pages use special swap entries that
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for bot
On 3/3/21 10:16 PM, Alistair Popple wrote:
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
Looks OK to me.
Reviewed-by:
Den 05.03.2021 17.31, skrev Noralf Trønnes:
> This adds a USB display driver with the intention that it can be
> used with future USB interfaced low end displays/adapters. The Linux
> gadget device driver will serve as the canonical device implementation.
>
> diff --git a/drivers/gpu/drm/gud/gu
https://bugzilla.kernel.org/show_bug.cgi?id=212137
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=212137
--- Comment #1 from Dennis Foster (m...@dennisfoster.us) ---
Created attachment 295743
--> https://bugzilla.kernel.org/attachment.cgi?id=295743&action=edit
systemd journal
--
You may reply to this email to add a comment.
You are receiving thi
https://bugzilla.kernel.org/show_bug.cgi?id=212137
Bug ID: 212137
Summary: kernel NULL pointer dereference, black screen when
using two graphics cards
Product: Drivers
Version: 2.5
Kernel Version: 5.11
Hardware: x86-64
On Mon, Mar 01, 2021 at 12:22:26PM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
> This binding is not used in any upstreamed DTS yet, so changing
> index of property 'j721e-intg' should not affect anything.
TI folks might disagree, but were
Artem Lapkin writes:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [4.503949] meson_ee_pwrc c883
On Sun, 28 Feb 2021 13:41:04 +0100, Konrad Dybcio wrote:
> Document the newly added PMI8994 compatible.
>
> Signed-off-by: Konrad Dybcio
> ---
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote:
> While Kepler does technically support 256x256 cursors, it turns out that
> Kepler actually has some additional requirements for scanout surfaces that
> we're not enforcing correctly, which aren't present on Maxwell and later.
> Cursor su
The driver build should work without IOMMUv2. In amdkfd/Makefile, we
have this condition:
ifneq ($(CONFIG_AMD_IOMMU_V2),)
AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
endif
In amdkfd/kfd_iommu.h we define inline stubs of the functions that are
causing your link-failures if IOMMU_V2 is not enabled:
On Mon, 8 Mar 2021 at 13:57, Philipp Zabel wrote:
>
> Hi Emil,
>
> On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The current imx8 code does not use the jpeg encoder. Remove the
> > unnecessary include.
> >
> > Cc: Ezequiel Garcia
> > Cc: Philipp Zab
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/
Applied on drm-misc-next.
Many thanks Raphaël & Yannick for your patch.
Note: I have updated the "From:" field to yannick.fer...@foss.st.com for more
consistency.
Philippe :-)
De : Yannick FERTRE - foss
Envoyé : lundi 8 mars 2021 10:10
À : Raphael GALLAIS-POU - f
06.03.2021 02:02, Michał Mirosław пишет:
> On Fri, Mar 05, 2021 at 12:45:51AM +0300, Dmitry Osipenko wrote:
>> 04.03.2021 02:08, Michał Mirosław пишет:
>>> On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote:
Display controller (DC) performs isochronous memory transfers, and thus,
Hi,
On Sat, Mar 06, 2021 at 11:56:45AM -0800, Rob Herring wrote:
> On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote:
> > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote:
> > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote:
> > > > On 22/02/2021 18:12:42+01
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
driver
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
---
drivers/gpu/drm/
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
Document all of the DRM_CAP_* defines.
v2 (Pekka):
- Describe what the bit depth is
- Expand on preferred dumb buffer memory access patterns
- Explain what a PRIME buffer is
- Mention DRM_IOCTL_PRIME_FD_TO_HANDLE and DRM_IOCTL_PRIME_HANDLE_TO_FD
- Explicitly reference CLOCK_REALTIME and CLOCK_MONO
On Monday, March 8th, 2021 at 9:20 AM, Pekka Paalanen
wrote:
> > > > +/**
> > > > + * DRM_CAP_CRTC_IN_VBLANK_EVENT
> > > > + *
> > > > + * If set to 1, the kernel supports reporting the CRTC ID in
> > > > + * &drm_event_vblank.crtc_id.
> > >
> > > Does this not apply also to the pageflip / atomi
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reported-by: kernel test robot
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912b
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reviewed-by: Rob Herring
---
.../display/bridge/lontium,lt8912b.yaml | 102 ++
MAINTAINERS | 5 +
2 files changed, 107 insertions(+)
create mode 100644
Documentati
Hi,
this patch set adds the support of the Lontium lt8912 MIPI to HDMI
bridge in the kernel.
It's only support the video part, not the audio part yet
since I don't have the datasheet of this component.
I get the current i2c configuration from Digi and
Boundary drivers.
Developed using the DB_DSIHD
Applied on drm-misc-next.
Many thanks Jagan for your patch and many thanks Thomas & Yannick for your
reviews & tests.
Philippe :-)
De : Linux-stm32 de la part
de Yannick FERTRE - foss
Envoyé : jeudi 4 mars 2021 09:49
À : Thomas Zimmermann; Jagan Teki; Ya
Hi Robert,
On Thu, 2021-03-04 at 11:27 +0800, Liu Ying wrote:
> Hi Robert,
>
> On Wed, 2021-03-03 at 16:34 +0100, Robert Foss wrote:
> > On Wed, 3 Mar 2021 at 08:23, Liu Ying wrote:
> > > Hi Robert,
> > >
> > > On Tue, 2021-03-02 at 15:22 +0100, Robert Foss wrote:
> > > > Hey Liu,
> > > >
> >
Hi Rob,
On Fri, 2021-03-05 at 16:42 -0600, Rob Herring wrote:
> On Thu, Feb 18, 2021 at 11:41:49AM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
> >
> > Signed-off-by: Liu Ying
> > ---
> > v3->v4:
> > * Add 'fsl,sc-resource' property. (Rob)
> >
> >
On 08/03/2021 09:16, Daniel Lezcano wrote:
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
R
On 2021/3/8 17:18, Chris Wilson wrote:
Quoting Jia-Ju Bai (2021-03-08 08:59:52)
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
It would not be EINVAL since that is used f
On Fri, 05 Mar 2021, Roland Scheidegger wrote:
> The vmwgfx ones look all good to me, so for
> 23-53: Reviewed-by: Roland Scheidegger
> That said, they were already signed off by Zack, so not sure what
> happened here.
Yes, they were accepted at one point, then dropped without a reason.
Since I
Quoting Jia-Ju Bai (2021-03-08 08:59:52)
> When i915_random_order() returns NULL to order, no error return code of
> igt_buddy_alloc_smoke() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.
It would not be EINVAL since that is used for a reference failure, but
in this cas
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
driver
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
Quoting Jia-Ju Bai (2021-03-08 09:07:22)
> When kcalloc() returns NULL to tsk or thread, no error code of
> igt_threaded_blt() is returned.
> To fix this bug, -ENOMEM is returned as error code.
Because we decided to skip the test if it could not be run due to
insufficient memory, as opposed to an
Tested-by: Yannick Fertre
On 2/22/21 10:23 AM, Raphael GALLAIS-POU - foss wrote:
From: Yannick Fertre
Standardize on the dev_ based logging.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 49 ++-
1 fil
Tested-by: Yannick Fertre
On 2/22/21 10:22 AM, Raphael GALLAIS-POU - foss wrote:
From: Yannick Fertre
Don't print error when probe deferred error is returned.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 9 +++--
1 file
When kcalloc() returns NULL to tsk or thread, no error code of
igt_threaded_blt() is returned.
To fix this bug, -ENOMEM is returned as error code.
Fixes: 0e99f939f08f ("drm/i915/selftests/blt: add some kthreads into the mix")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/dr
https://bugzilla.kernel.org/show_bug.cgi?id=212107
Martin (martin...@gmx.com) changed:
What|Removed |Added
Severity|normal |blocking
--
You may reply t
https://bugzilla.kernel.org/show_bug.cgi?id=212107
--- Comment #3 from Martin (martin...@gmx.com) ---
(In reply to Dieter Nützel from comment #2)
> It could be the ZeroCore thing, which has finally landed with 5.11.
> Please verify, that your gfx fans stopped with 5.11 and running with all
> kerne
On 02/03/2021 05:22, Artem Lapkin wrote:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [4.503949]
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
Fixes: 1fe3818d17c9 ("drm/i915/selftests: try to rein in alloc_smoke")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
d
Hi Paul,
having individual functions for each mode only makes sense if the
decision is at compile time. But in patch 5, you're working around your
earlier design by introducing in-driver helpers that select the correct
CMA function.
In SHMEM helpers we have the flag map_wc in the GEM structu
Following warning is found when using W=1 to build kernel:
In function ‘nvkm_udevice_info’,
inlined from ‘nvkm_udevice_mthd’ at
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:195:10:
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:164:2: warning: ‘strncpy’
specified bound 16 equals dest
On Sat, 06 Mar 2021 10:56:49 +
Simon Ser wrote:
> On Friday, March 5th, 2021 at 9:28 AM, Pekka Paalanen
> wrote:
>
> > > +/**
> > > + * DRM_CAP_DUMB_PREFERRED_DEPTH
> > > + *
> > > + * The preferred depth (in bits) for dumb buffers.
> >
> > this is literally depth, not bits per pixel, ri
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.11.3 |5.11.4
--
You may reply
R-b me. Pushed, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Signed-off-by: Jianhui Zhao
---
Documentation/gpu/todo.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 40ccac61137e..b7f1acb355f5 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -700,
On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
> With the module parameter ingenic-drm.cached_gem_buffers, it is possible
> to specify that we want GEM buffers backed by non-coherent memory.
>
> This dramatically speeds up software rendering on Ingenic SoCs, even for
> tasks where write-
93 matches
Mail list logo
