Am 17.03.21 um 17:08 schrieb Daniel Gomez:
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
Good catch, not sure if that can ever happen in practice but better save
than sorry.
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/am
On Thu, 18 Mar 2021 at 08:49, Christian König wrote:
>
> Am 17.03.21 um 17:08 schrieb Daniel Gomez:
> > If userptr pages have been pinned but not bounded,
> > they remain uncleared.
> >
> > Signed-off-by: Daniel Gomez
>
> Good catch, not sure if that can ever happen in practice but better save
>
https://bugzilla.kernel.org/show_bug.cgi?id=212255
--- Comment #5 from Felice Tufo (i...@felicetufo.com) ---
Tested also on 5.11.7
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
Reviewed-by: Christian König
Von: Daniel Gomez
Gesendet: Donnerstag, 18. März 2021 09:32
Cc: dag...@gmail.com ; Daniel Gomez ;
Deucher, Alexander ; Koenig, Christian
; David Airlie ; Daniel Vetter
; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.o
Hi,
Here is a series that enables the higher resolutions on the HDMI0 Controller
found in the BCM2711 (RPi4).
In order to work it needs a few adjustments to config.txt, most notably to
enable the enable_hdmi_4kp60 option.
The firmware also has a glitch at the moment and will not properly release
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Acked-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/v
The HDMI controller on the BCM2711 includes a scrambler in order to
reach the modes that require it. Let's add the support for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 56 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 ++
2 files changed
Now that we have the infrastructure in place, we can raise the maximum
pixel rate we can reach for HDMI0 on the BCM2711.
HDMI1 is left untouched since its pixelvalve has a smaller FIFO and
would need a clock faster than what we can provide to support the same
modes.
Reviewed-by: Dave Stevenson
S
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Signed-off-by:
The BVB clock rate computation doesn't take into account a mode clock of
594MHz that we're going to need to support 4k60.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_
On Wed, Mar 17, 2021 at 09:57:33PM +0300, Dmitry Osipenko wrote:
[...]
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -618,6 +619,9 @@ static int tegra_plane_atom
Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it
On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote:
>
>
> On 2/11/2021 7:34 AM, Daniel Vetter wrote:
> > On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
> >>
> >> On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> >>> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
> This pat
On 17/03/2021 23:40, Jason Ekstrand wrote:
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
I haven't checked if userspace uses this so assuming that is fine, the
only thing that remains is preparing the IGTs for t
s/bariers/barriers/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 037b0e3ccbed..25fc7f44fee0 100644
---
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native drivers to take-over control of the
hardware.
The new driver, called simpledrm, binds to a simple-frambuffer platform
device. The kernel's boot code creates such devices for firmware-provided
fra
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c| 9 +
drivers/gpu/drm/mgag200/mgag
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Aperture helpers provide the infrastructure for platform
drivers t
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c | 87 +
include/drm/drm_format_helper.h
This displays a console on simpledrm's framebuffer. The default
framebuffer format is being used.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tiny/s
The simpledrm driver is a DRM driver for simplefb framebuffers as
provided by the kernel's boot code. This driver enables basic
graphical output on many different graphics devices that are provided
by the platform (e.g., EFI, VESA, embedded framebuffers).
With the kernel's simplefb infrastructure,
Fbdev's helpers for handling conflicting framebuffers are related to
framebuffer apertures, not console emulation. Therefore move them into a
drm_aperture.h, which will contain the interfaces for the new aperture
helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
Documentation/
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/t
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kick-out the simpledrm
driver before taking over the device.
v2:
* adapt to aperture changes
* use drm_dev_unplug() and drm_dev_enter/exit()
* don't split error st
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
v2:
* add Device Tree match table
* clean-up parser wrappers
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simple
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
v2:
* use strscpy()
Signed-off-by: Thomas Zimmermann
Tested-b
18.03.2021 12:31, Michał Mirosław пишет:
>> static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
>> @@ -2430,6 +2781,7 @@ static const struct tegra_dc_soc_info
>> tegra194_dc_soc_info = {
>> .has_nvdisplay = true,
>> .wgrps = tegra194_dc_wgrps,
>> .num_wgrps = ARRAY_SI
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
s/instatiated/instantiated/
s/unreference/unreferenced/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/drm_property.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 6ee04803c362..27c824a6eb60 1
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At that point, We had to make sure each job is in the mirror
SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed
due to bad interaction with b8dab65b5ac3 ("drm/msm/dpu: Move
DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in
parallel.
Fixes: d21fc5dfc3df ("drm/msm/dpu1: add support for qseed3lite used on sm8250")
Si
Hi
Am 18.03.21 um 11:39 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks
s/initialy/initially/
s/desined/designed/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/meson/meson_venc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 5e2236ec189f..3c55ed003359 100644
drm-misc-fixes-2021-03-18:
drm-misc-fixes for v5.12-rc4:
- Make ttm_bo_unpin() not wraparound on too many unpins.
- Fix coccicheck warning in omap.
The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb:
drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100)
are av
s/traing/training/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index c325d6f53a71..db18e4f6cf5f 100644
--- a/driv
Hi Dave & Daniel -
Covering for Rodrigo during his absence this week.
drm-intel-fixes-2021-03-18:
drm/i915 fixes for v5.12-rc4:
- Workaround async flip + VT-d frame corruption on HSW/BDW
- Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+
BR,
Jani.
The following changes since
On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst
wrote:
>
> drm-misc-fixes-2021-03-18:
> drm-misc-fixes for v5.12-rc4:
> - Make ttm_bo_unpin() not wraparound on too many unpins.
> - Fix coccicheck warning in omap.
Still missing the 2 patches from drm-misc-next-fixes, and those being
left out al
As per the current implementation, after FSC (Full Scale Current)
and brightness update the sync bits are set-then-cleared.
But, the FSC and brightness sync takes place when the sync bits are
set (e.g. on a rising edge). So the hardware team recommends a
clear-then-set approach in order to guarante
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adoptin
This patch series has the following two WLED fixes
1. As per the current implementation, for WLED5, after
the FSC (Full Scale Current) update the driver is incorrectly
toggling the MOD_SYNC register instead of toggling the SYNC register.
The patch 1/2 fixes this by toggling the SYNC re
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
v2: consistently return int
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 57 -
drivers/gpu/drm/ttm/ttm_device.c| 29 ++
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
v3: fix rebase fallout, num_pages should be 32bit
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 29 --
drivers/gpu/drm/ttm/ttm_bo_util.c
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
dri
On Thu, Mar 18, 2021 at 10:38:11AM +0100, Christian König wrote:
> Am 17.03.21 um 23:19 schrieb Jason Ekstrand:
> > From: Christian König
> >
> > Add a helper to iterate over all fences in a dma_fence_array object.
> >
> > v2 (Jason Ekstrand)
> > - Return NULL from dma_fence_array_first if hea
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
>
> On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> >
> > On Thu, 11 Mar 2021, Lee Jones wrote:
> >
> > > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> > >
> > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > > On Fri, 05
On Thu, Mar 18, 2021 at 04:07:39PM +0530, Bhaskar Chowdhury wrote:
>
> s/instatiated/instantiated/
> s/unreference/unreferenced/
>
> Signed-off-by: Bhaskar Chowdhury
Queued for 5.13 in drm-misc-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_property.c | 4 ++--
> 1 file chan
On Wed, Mar 17, 2021 at 06:40:12PM -0500, Jason Ekstrand wrote:
> From: Ashutosh Dixit
>
> The rationale for this change is roughly as follows:
>
> 1. The functionality can be done entirely in userspace with a
> combination of mmap + memcpy
>
> 2. The only reason anyone in userspace is st
https://bugzilla.kernel.org/show_bug.cgi?id=212327
Bug ID: 212327
Summary: i915 / Kernel Mode Setting - Distorts Screen
Product: Drivers
Version: 2.5
Kernel Version: 5.12.0-rc3
Hardware: Intel
OS: Linux
Tree:
https://bugzilla.kernel.org/show_bug.cgi?id=212327
--- Comment #1 from RK (ros...@rkarim.xyz) ---
Created attachment 295915
--> https://bugzilla.kernel.org/attachment.cgi?id=295915&action=edit
image of screen issue
--
You may reply to this email to add a comment.
You are receiving this mail b
On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote:
> s/instatiated/instantiated/
> s/unreference/unreferenced/
[]> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
[]
> @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get);
> * @id: id of the blob property
https://bugzilla.kernel.org/show_bug.cgi?id=212137
Dennis Foster (m...@dennisfoster.us) changed:
What|Removed |Added
Status|NEW |RESOLVED
R
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/
https://bugzilla.kernel.org/show_bug.cgi?id=212281
--- Comment #2 from Tomas Sandven (tomas@sandven.email) ---
Created attachment 295919
--> https://bugzilla.kernel.org/attachment.cgi?id=295919&action=edit
Full dmesg output
--
You may reply to this email to add a comment.
You are receiving th
https://bugzilla.kernel.org/show_bug.cgi?id=212281
--- Comment #3 from Tomas Sandven (tomas@sandven.email) ---
(In reply to Alex Deucher from comment #1)
> Please attach your full dmesg output and xorg log (if using X).
I added full dmesg output. I have rebooted since the first error, so the two
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3]
[If your
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 035bbc044a3b..6a0b267d4fe6 100644
--- a/inclu
Op 18-03-2021 om 13:31 schreef Daniel Vetter:
> On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst
> wrote:
>> drm-misc-fixes-2021-03-18:
>> drm-misc-fixes for v5.12-rc4:
>> - Make ttm_bo_unpin() not wraparound on too many unpins.
>> - Fix coccicheck warning in omap.
> Still missing the 2 patches
[why]
MST topology print was missing fec logging and pdt printed
as an int wasn't clear. vcpi and payload info were also logged as an
arbitrary series of ints which require the user to know the ordering
of the prints, making the logs difficult to use.
[how]
-add fec logging
-add pdt parsing into s
The vc4_plane_atomic_async_update function assigns twice in a row the
src_h field in the drm_plane_state structure to the same value. Remove
the second one.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_plane.c | 1 -
1 file changed, 1 deletion(-)
diff --
From: Dom Cobley
Experimentally have found PV on hvs4 reports fifo full
error with expected settings and does not with one less
This appears as:
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done
timed out
with bit 10 of PV_STAT set "HVS driving pixels when the PV FI
The vc4_plane_mode_set function still accesses the scaler target width
and height using the older register layout while it was updated with the
BCM2711, and the proper defines got introduced when we started to
support it.
Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
Reviewed-b
On 2021-03-18 6:41 a.m., Zhang, Jack (Jian) wrote:
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey
Let me summarize the background of this patch:
In TDR resubmit step “amdgpu_device_recheck_guilty_jobs,
It will submit first jobs of each ring and do guilty job re-check.
At
https://bugzilla.kernel.org/show_bug.cgi?id=212333
Bug ID: 212333
Summary: Bisected: 5.11.7 breaks amdgpu resume from S3
Product: Drivers
Version: 2.5
Kernel Version: 5.11.7
Hardware: x86-64
OS: Linux
Tree: Ma
https://bugzilla.kernel.org/show_bug.cgi?id=212333
--- Comment #1 from Timo Valtoaho (timo.valto...@gmail.com) ---
Created attachment 295923
--> https://bugzilla.kernel.org/attachment.cgi?id=295923&action=edit
git bisect log
--
You may reply to this email to add a comment.
You are receiving t
https://bugzilla.kernel.org/show_bug.cgi?id=212333
--- Comment #2 from Timo Valtoaho (timo.valto...@gmail.com) ---
Created attachment 295927
--> https://bugzilla.kernel.org/attachment.cgi?id=295927&action=edit
lspci
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=212333
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.
Note though I'm not entirely clear on this - on one of the machi
From: Tvrtko Ursulin
"Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second
post of a somewhat controversial feature, now upgraded to patch status.
I quote the "watchdog" becuase in classical sense watchdog would allow userspace
to ping it and so remain alive.
I quote "r
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests
From: Tvrtko Ursulin
Disallow sentinel requests follow previous sentinels to make request
cancellation work better when faced with a chain of requests which have
all been marked as in error.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
1 file c
From: Tvrtko Ursulin
With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.
v2:
* Check against the correct request!
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_execlists_submissio
From: Tvrtko Ursulin
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
c
From: Tvrtko Ursulin
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a
From: Tvrtko Ursulin
Module parameter is added (request_timeout_ms) to allow configuring the
default request/fence expiry.
Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i9
Actually-NAK this. I just realized I've been misreading the bug and that this
doesn't actually seem to be fixed. Will resend once I figure out what's going on
On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> Looks like that there actually are another subset of laptops on the market
> that do
On 3/18/21 7:25 AM, Joe Perches wrote:
> On Thu, 2021-03-18 at 16:07 +0530, Bhaskar Chowdhury wrote:
>> s/instatiated/instantiated/
>> s/unreference/unreferenced/
>
> []> diff --git a/drivers/gpu/drm/drm_property.c
> b/drivers/gpu/drm/drm_property.c
> []
>> @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_p
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
> b/drivers/gpu/drm/amd/amdgp
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
>
> On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
> >
> > s/traing/training/
> >
> > Signed-off-by: Bhaskar Chowdhury
> > ---
> > drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20210318]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
linus/master v5.12-rc3]
[If your patch is applied to the wrong git tree, k
On 3/18/21 3:19 AM, Bhaskar Chowdhury wrote:
>
> s/bariers/barriers/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
Hi!
Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a):
> Hi,
>
> Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
> the RaspberryPi4.
>
> I took the same approach than what dw-hdmi did already, turning a bunch of
> functions found in that driver in
On 3/18/21 4:00 AM, Bhaskar Chowdhury wrote:
>
> s/initialy/initially/
> s/desined/designed/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/meson/meson_venc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/meson/
On 3/17/21 11:26 PM, Bhaskar Chowdhury wrote:
> s/modueles/modules/ two different places
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/msm/dp/dp_power.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/
Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a):
> On 17/03/2021 16:43, Maxime Ripard wrote:
> > The atomic_get_output_bus_fmts bridge callback is there to list the
> > available formats for output by decreasing order of preference.
> >
> > On HDMI controllers, we have a fai
On 3/18/2021 3:16 AM, Daniel Vetter wrote:
> On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote:
>>
>>
>> On 2/11/2021 7:34 AM, Daniel Vetter wrote:
>>> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> On Tue, Jan 26, 2021 at 01
On 3/18/21 4:26 PM, Christian König wrote:
Am 18.03.21 um 15:43 schrieb Nirmoy:
Hi Christian,
On 3/18/21 1:47 PM, Christian König wrote:
/**
* ttm_bo_uses_embedded_gem_object - check if the given bo uses the
diff --git a/include/drm/ttm/ttm_device.h
b/include/drm/ttm/ttm_device.h
inde
On 17/03/2021 19:25, Rob Clark wrote:
On Mon, Mar 1, 2021 at 1:41 PM Dmitry Baryshkov
wrote:
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[skipped]
diff
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066]
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066]
On 14:12 Thu 18 Mar 2021, Alex Deucher wrote:
On Thu, Mar 18, 2021 at 2:08 PM Randy Dunlap wrote:
On 3/18/21 4:33 AM, Bhaskar Chowdhury wrote:
>
> s/traing/training/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+),
s/traing/training/
...Plus the entire sentence construction for better readability.
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Alex and Randy's suggestions incorporated.
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --g
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This is actually wrong though, as we only
want to be concerned that the actual width/height of the plane are the
same.
On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> want to be conce
On Thu, 2021-03-18 at 18:13 -0400, Ilia Mirkin wrote:
> On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul wrote:
> >
> > Found this while trying to make some changes to the kms_cursor_crc test.
> > curs507a_acquire checks that the width and height of the cursor framebuffer
> > are equal (asyw->image.{w,
So basically we see this warning only in case of bigjoiner when
drm_atomic_check gets called without setting the state->allow_modeset flag.
So do you think that in i915, in intel_atomic_check_bigjoiner() we should only
steal the crtc when allow_modeset flag is set in state?
If we add this check th
Found this while trying to make some changes to the kms_cursor_crc test.
curs507a_acquire checks that the width and height of the cursor framebuffer
are equal (asyw->image.{w,h}). This isn't entirely correct though, as the
height of the cursor can be larger than the size of the cursor, as long as
t
(going to try to take a look at this tomorrow JFYI)
On Thu, 2021-03-18 at 11:55 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info were also logged as an
> arbitrary series of ints which require the user to k
s/proces/process/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index bf3857867f51..c1d5a3085bae 100644
--- a/drive
Hi Parshuram,
Thank you for the patch.
On Thu, Mar 18, 2021 at 07:45:30AM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 24 +++
1 - 100 of 128 matches
Mail list logo
