Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by >mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
This patch series addresses potential use-after-free errors when dereferencing
pointers to struct drm_master. These were identified after one such bug was
caught by Syzbot in drm_getunique():
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
The series is broken up
Hi Robin,
thinks for you reply.
I had send more detal to Steve in another mail,thinks for your
messages.
?? Mon, 28 Jun 2021 15:17:51 +0100
Robin Murphy :
> On 2021-06-28 11:48, Steven Price wrote:
> > On 25/06/2021 10:49, Chunyou Tang wrote:
> >> Hi Steve,
> >>
Hi Steve,
thinks for your reply.
I set the pte in arm_lpae_prot_to_pte(),
***
/*
* Also Mali has its own notions of shareability wherein its
Inner
* domain covers the cores within the GPU,
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb Marek Vasut:
On 6/24/21 2:01 PM, Lucas Stach wrote:
Am Dienstag, dem 22.06.2021 um 11:33 +0200 schrieb Marek Vasut:
On 6/22/21 9:28 AM, Lucas Stach wrote:
Am Montag, dem 21.06.2021 um 18:30 +0200
On 2021-06-28 17:55, Bjorn Andersson wrote:
On Mon 28 Jun 19:31 CDT 2021, abhin...@codeaurora.org wrote:
Hi Bjorn
On 2021-06-28 17:22, Bjorn Andersson wrote:
> The debugfs interface contains the knobs to make the DisplayPort
> controller output a test pattern, unfortunately there's nothing
>
On Mon 28 Jun 19:31 CDT 2021, abhin...@codeaurora.org wrote:
> Hi Bjorn
>
> On 2021-06-28 17:22, Bjorn Andersson wrote:
> > The debugfs interface contains the knobs to make the DisplayPort
> > controller output a test pattern, unfortunately there's nothing
> > currently that actually enables the
Hi Bjorn
On 2021-06-28 17:22, Bjorn Andersson wrote:
The debugfs interface contains the knobs to make the DisplayPort
controller output a test pattern, unfortunately there's nothing
currently that actually enables the defined test pattern.
Fixes: de3ee25473ba ("drm/msm/dp: add debugfs nodes
The debugfs interface contains the knobs to make the DisplayPort
controller output a test pattern, unfortunately there's nothing
currently that actually enables the defined test pattern.
Fixes: de3ee25473ba ("drm/msm/dp: add debugfs nodes for video pattern tests")
Signed-off-by: Bjorn Andersson
Many of the DSI flags have names opposite to their actual effects,
e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
be disabled. Fix this by including _NO_ in the flag names, e.g.
MIPI_DSI_MODE_NO_EOT_PACKET.
Signed-off-by: Nicolas Boichat
---
I considered adding _DISABLE_
On Mon, Jun 28, 2021 at 7:10 PM Linus Walleij wrote:
>
> On Wed, Mar 3, 2021 at 11:31 AM Nicolas Boichat wrote:
> > On Mon, Mar 1, 2021 at 4:59 PM Linus Walleij
> > wrote:
>
> > > > dsi->mode_flags =
> > > > MIPI_DSI_CLOCK_NON_CONTINUOUS |
> > > > -
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
From: Christian König
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koe...@amd.com
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to drm-tip/drm-tip anholt/for-next v5.13 next-20210628]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:54 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21
On 6/28/21 9:50 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:03 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Auld, Matthew ; lkp
Subject: Re: [PATCH v3 1/5] drm/i915/gem:
On 6/28/21 9:45 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
Subject: [PATCH v3 5/5]
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:03 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 8:11
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew ;
>maarten.lankho...@linux.intel.com; Thomas Hellström
>; Ruhl; Ruhl, Michael J
>
>Subject: [PATCH v3 4/5]
On 6/28/21 9:27 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:15 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Auld, Matthew
Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem:
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:15 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for
>the gem object
Add support for alpha blending properties. Setup the plane blend state
according to those properties.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 43 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 10 --
2 files changed, 37
On Mon, 2021-06-28 at 18:53 +, Ruhl, Michael J wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of
> > Thomas Hellström
> > Sent: Monday, June 28, 2021 10:46 AM
> > To: intel-...@lists.freedesktop.org;
> > dri-devel@lists.freedesktop.org
> > Cc: Thomas Hellström ;
On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
; lkp
Subject: [PATCH v3 1/5]
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>; lkp
>Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
https://bugzilla.kernel.org/show_bug.cgi?id=213599
--- Comment #6 from Frank Kruger (fkrue...@mailbox.org) ---
Fixed with kernel 5.13, thanks.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
On 6/28/21 6:28 PM, Matthew Auld wrote:
On 28/06/2021 15:46, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
Hi Stephen,
Thanks for the review.
On 2021-06-17 15:33, Stephen Boyd wrote:
Quoting maitreye (2021-06-16 18:08:54)
From: Maitreyee Rao
Add trace points across the MSM DP driver to help debug
interop issues.
Signed-off-by: Maitreyee Rao
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +++--
Am 18.06.21 um 11:11 schrieb Werner Sembach:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check which one actually
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to drm-tip/drm-tip anholt/for-next v5.13 next-20210628]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
https://bugzilla.kernel.org/show_bug.cgi?id=213599
Paulo Marcos de Souza Arruda do Nascimento (contato-mygh...@protonmail.com)
changed:
What|Removed |Added
Status|NEW
Am 2021-06-17 um 3:16 p.m. schrieb Ralph Campbell:
>
> On 6/17/21 8:16 AM, Alex Sierra wrote:
>> From: Ralph Campbell
>>
>> ZONE_DEVICE struct pages have an extra reference count that
>> complicates the
>> code for put_page() and several places in the kernel that need to
>> check the
>>
Applied. Thanks!
Alex
On Fri, Jun 25, 2021 at 4:14 PM Harry Wentland wrote:
>
> On 2021-06-23 6:30 a.m., Michal Suchanek wrote:
> > Also copy over the part that makes old gcc handling cross-platform.
> >
> > Fixes: df7a1658f257 ("drm/amdgpu/dc: fix DCN3.1 Makefile for PPC64")
> > Fixes:
On 28/06/2021 15:46, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the
Hi Doug,
On Mon, Jun 28, 2021 at 08:34:04AM -0700, Doug Anderson wrote:
> On Mon, Jun 28, 2021 at 6:33 AM Laurent Pinchart wrote:
> > On Mon, Jun 28, 2021 at 05:46:24PM +0530, rajee...@codeaurora.org wrote:
> > > On 27-06-2021 23:48, Laurent Pinchart wrote:
> > > > On Sat, Jun 26, 2021 at
https://bugzilla.kernel.org/show_bug.cgi?id=213561
--- Comment #14 from Marco Scardovi (ma...@scardovi.com) ---
Can confirm on kernel 5.13-final is fixed. 44°C instead of 73°C on idle
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
On 6/28/21 3:57 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210625:
>
on i386 or 86_64:
../drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_vram_manager_init':
../drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:678:8: error: implicit declaration of
function 'ttm_range_man_init'; did
On 28/06/2021 15:46, Thomas Hellström wrote:
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by:
Hi,
On Mon, Jun 28, 2021 at 6:33 AM Laurent Pinchart
wrote:
>
> Hi Rajeev,
>
> On Mon, Jun 28, 2021 at 05:46:24PM +0530, rajee...@codeaurora.org wrote:
> > On 27-06-2021 23:48, Laurent Pinchart wrote:
> > > On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
> > >> Do not give a
Am 25.06.21 um 19:28 schrieb Nirmoy Das:
Return early for AMDGPU_PL_PREEMPT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5
On 28/06/2021 15:46, Thomas Hellström wrote:
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
Looks reasonable to me,
Reviewed-by: Matthew Auld
On 2021-06-01 6:52 a.m., Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52
Am 25.06.21 um 04:03 schrieb huqiqiao:
malloc_array + __GFP_ZERO is the same with kvcalloc.
Signed-off-by: huqiqiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
[Public]
Applied. Thanks. For whatever reason, I never got this patch and couldn't
find it in patchwork.
Alex
From: Koenig, Christian
Sent: Wednesday, June 23, 2021 4:25 AM
To: Tiezhu Yang ; Deucher, Alexander
Cc: airl...@linux.ie ;
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf map time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
Signed-off-by: Thomas Hellström
---
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c |
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
We want to be able to explicitly migrate objects between gem memory
regions, initially for display and dma-buf, but there might be more
use-cases coming up.
Introduce a gem migrate interface, add a selftest and use it for
display fb pinning and dma-buf mapping.
This series should make
On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin
wrote:
>
>
>
> On 14/05/2021 16:10, Christian König wrote:
> > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >>
> >> On 14/05/2021 15:56, Christian König wrote:
> >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
>
> On 14/05/2021 14:53,
On 2021-06-28 11:48, Steven Price wrote:
On 25/06/2021 10:49, Chunyou Tang wrote:
Hi Steve,
Thinks for your reply.
When I only set the pte |= ARM_LPAE_PTE_SH_NS;there have no "GPU
Fault",When I set the pte |= ARM_LPAE_PTE_SH_IS(or
ARM_LPAE_PTE_SH_OS);there have "GPU Fault".I
https://bugzilla.kernel.org/show_bug.cgi?id=213599
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On 28/06/2021 08:42, Boris Brezillon wrote:
> From: Steven Price
>
> The hardware has a set of '_NEXT' registers that can hold a second job
> while the first is executing. Make use of these registers to enqueue a
> second job per slot.
>
> v3:
> * Fix the done/err job dequeuing logic to get a
Hi Rajeev,
On Mon, Jun 28, 2021 at 05:46:24PM +0530, rajee...@codeaurora.org wrote:
> On 27-06-2021 23:48, Laurent Pinchart wrote:
> > On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
> >> Do not give a warning for the eDP panels if the "bus_format" is
> >> not specified, since most
https://bugzilla.kernel.org/show_bug.cgi?id=213569
--- Comment #5 from Martin (martin...@gmx.com) ---
(In reply to James from comment #3)
> This is a legitimate bug which is present starting 5.12.13 and the issue was
> said to have been fixed starting 5.13-rc8. I wanted to comment out of
>
From: Tim Gover
Adjust the DVP enable/disable sequence to avoid a pixel getting stuck
in an internal, non resettable FIFO within PixelValve when changing
HDMI resolution.
The blank pixels features of the DVP can prevent signals back to
pixelvalve causing it to not clear the FIFO. Adjust the
Hi "Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.13 next-20210628]
[If your patch is applied to the wrong git
The encoder retrieval code has been a source of bugs and glitches in the
past and the crtc <-> encoder association been wrong in a number of
different ways.
Add some logging to quickly spot issues if they occur.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
1 file
It turns out the encoder retrieval code, in addition to being
unnecessarily complicated, has a bug when only the planes and crtcs are
affected by a given atomic commit.
Indeed, in such a case, either drm_atomic_get_old_connector_state or
drm_atomic_get_new_connector_state will return NULL and
The load tracker was initially designed to report and warn about a load
too high for the HVS. To do so, it computes for each plane the impact
it's going to have on the HVS, and will warn (if it's enabled) if we go
over what the hardware can process.
While the limits being used are a bit
Depending on a given HVS output (HVS to PixelValves) and input (planes
attached to a channel) load, the HVS needs for the core clock to be
raised above its boot time default.
Failing to do so will result in a vblank timeout and a stalled display
pipeline.
Signed-off-by: Maxime Ripard
---
If we have a state already and disconnect/reconnect the display, the
SCDC messages won't be sent again since we didn't go through a disable /
enable cycle.
In order to fix this, let's call the vc4_hdmi_enable_scrambling function
in the detect callback if there is a mode and it needs the scrambler
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.
Acked-by: Thomas Zimmermann
vc4_crtc_config_pv() retrieves the encoder again, even though its only
caller, vc4_crtc_atomic_enable(), already did.
Pass the encoder pointer as an argument instead of going through all the
connectors to retrieve it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 7
We'll need that function in vc4_kms to compute the core clock rate
requirements.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c
Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the
detect hook, if we had an HPD GPIO we would only rely on it and return
whatever state it was in.
However, that commit changed that by mistake to only consider the case
where we have a GPIO and it returns a logical high, and
Commit 9d44a8d5 ("drm/vc4: Fall back to using an EDID probe in the
absence of a GPIO.") added some code to read the EDID through DDC in the
HDMI driver detect hook since the Pi3 had no HPD GPIO back then.
However, commit b1b8f45b3130 ("ARM: dts: bcm2837: Add missing GPIOs of
Expander") changed
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.
Let me know what you think,
Maxime
---
Changes from v4:
- Removed the
Am 28.06.21 um 14:28 schrieb Maxime Ripard:
> On Thu, Jun 17, 2021 at 07:41:09PM +0200, Stefan Wahren wrote:
>> Hi Maxime,
>>
>> Am 17.06.21 um 17:25 schrieb Maxime Ripard:
>>> Hi Stefan,
>>>
>>> On Sat, Jun 12, 2021 at 12:04:08PM +0200, Stefan Wahren wrote:
Hi Maxime,
Am 04.06.21
On Thu, Jun 17, 2021 at 07:41:09PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 17.06.21 um 17:25 schrieb Maxime Ripard:
> > Hi Stefan,
> >
> > On Sat, Jun 12, 2021 at 12:04:08PM +0200, Stefan Wahren wrote:
> >> Hi Maxime,
> >>
> >> Am 04.06.21 um 11:02 schrieb Maxime Ripard:
> >>> Hi Stefan,
Hi Laurent,
On 27-06-2021 23:48, Laurent Pinchart wrote:
Hi Rajeev,
On Sat, Jun 26, 2021 at 10:21:06PM +0530, Rajeev Nandan wrote:
Do not give a warning for the eDP panels if the "bus_format" is
not specified, since most eDP panels can support more than one
bus formats and this can be
https://bugzilla.kernel.org/show_bug.cgi?id=213561
--- Comment #13 from Marco Scardovi (ma...@scardovi.com) ---
(In reply to Linux_Chemist from comment #12)
> (In reply to Marco Scardovi from comment #11)
> > Hi everyone, I'm facing same issue here on kernel 5.12.13 with the AMD
> 3200U
> > in an
tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-gem-Introduce-a-migrate-interface/20210628-171204
base: git://anongit.freedeskto
On 6/24/21 9:30 PM, Thomas Hellström wrote:
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able
On Mon, 28 Jun 2021 11:46:08 +0200
Lucas Stach wrote:
> Am Donnerstag, dem 24.06.2021 um 16:08 +0200 schrieb Boris Brezillon:
> > The panfrost driver tries to kill in-flight jobs on FD close after
> > destroying the FD scheduler entities. For this to work properly, we
> > need to make sure the
On Wed, Mar 3, 2021 at 11:31 AM Nicolas Boichat wrote:
> On Mon, Mar 1, 2021 at 4:59 PM Linus Walleij wrote:
> > > dsi->mode_flags =
> > > MIPI_DSI_CLOCK_NON_CONTINUOUS |
> > > - MIPI_DSI_MODE_EOT_PACKET;
> > > +
https://bugzilla.kernel.org/show_bug.cgi?id=213561
--- Comment #12 from Linux_Chemist (untaintablean...@hotmail.co.uk) ---
(In reply to Marco Scardovi from comment #11)
> Hi everyone, I'm facing same issue here on kernel 5.12.13 with the AMD 3200U
> in an HP-15s laptop. Can you confirm these
On 25/06/2021 10:49, Chunyou Tang wrote:
> Hi Steve,
> Thinks for your reply.
> When I only set the pte |= ARM_LPAE_PTE_SH_NS;there have no "GPU
> Fault",When I set the pte |= ARM_LPAE_PTE_SH_IS(or
> ARM_LPAE_PTE_SH_OS);there have "GPU Fault".I don't know how the pte
> effect this
On 6/28/21 12:59 PM, Matthew Auld wrote:
On 28/06/2021 10:21, Thomas Hellström wrote:
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
-
On 28/06/2021 10:21, Thomas Hellström wrote:
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
- Added a R-B.
- Fixed up the code comment a bit.
On 6/28/21 12:20 PM, Matthew Auld wrote:
On 28/06/2021 10:38, Thomas Hellström wrote:
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem
only
Commit 6b36fa6143f6 ("drm/amdgpu: add umc v8_7_0 IP headers") adds the new
file ./drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h with
DOS line endings, which is very uncommon for the kernel repository.
Rectify the line endings in this file with dos2unix.
Identified by a checkpatch
On 28/06/2021 10:38, Thomas Hellström wrote:
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1
On 14/05/2021 16:10, Christian König wrote:
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
Hi,
On Thu, Jun 24, 2021 at 03:51:05PM +0300, Laurent Pinchart wrote:
> CC'ing Maxime Ripard.
>
> Maxime, is this similar to the issue we've recently discussed with the
> VC4 DSI encoder ?
>
> On Thu, Jun 24, 2021 at 10:39:48PM +1000, Jonathan Liu wrote:
> > On Thu, 24 Jun 2021 at 22:34, Jagan
Hi,
On Mon, Jun 21, 2021 at 05:18:22PM +0100, Dave Stevenson wrote:
> Hi Maxime
>
> On Mon, 21 Jun 2021 at 17:05, Maxime Ripard wrote:
> >
> > Hi Laurent,
> >
> > On Sun, Jun 20, 2021 at 04:44:33AM +0300, Laurent Pinchart wrote:
> > > Hi Maxime,
> > >
> > > I'm testing this, and I'm afraid it
On 28/06/2021 08:42, Boris Brezillon wrote:
> If the process who submitted these jobs decided to close the FD before
> the jobs are done it probably means it doesn't care about the result.
>
> v4:
> * Don't disable/restore irqs when taking the job_lock (not needed since
> this lock is never
Am Montag, dem 28.06.2021 um 09:41 +0200 schrieb Boris Brezillon:
> Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU
> reset. This leads to extra complexity when we need to synchronize timeout
> works with the reset work. One solution to address that is to have an
> ordered
On 2021-06-27 09:47, Andy Yan wrote:
When iommu itself is disabled in dts, we should
fallback to non-iommu buffer, check iommu parent
is meanless here.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Il 28/06/21 10:50, Robert Foss ha scritto:
The downstream dts lists this value as 0x494, and not
0x45c.
Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog")
Signed-off-by: Robert Foss
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
1 file
1 - 100 of 161 matches
Mail list logo
