+ Pavel
> -Original Message-
> From: Steven Price
> Sent: 12 July 2021 16:58
> To: Daniel Vetter ; David Airlie ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann
> Cc: Steven Price ; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; Biju Das ;
> Laurent Pinchart
From: Frank Wunderlich
bridge->driver_private is not set (NULL) so use bridge_to_dpi(bridge)
like it's done in bridge_atomic_get_output_bus_fmts
Fixes: ec8747c52434 ("drm/mediatek: dpi: Add bus format negotiation")
Signed-off-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 2 +-
Use swap() instead of implementing it since it makes code more clean.
Signed-off-by: Salah Triki
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
On 7/6/21 10:49 AM, Thomas Zimmermann wrote:
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's defi
Hi Doug,
On 12-07-2021 20:30, Douglas Anderson wrote:
We were getting a depmod error:
depmod: ERROR: Cycle detected: drm_kms_helper -> drm ->
drm_kms_helper
It looks like the rule is that drm_kms_helper can call into drm, but
drm can't call into drm_kms_helper. That means we've got to move
On Mon, 12 Jul 2021 12:15:59 -0400
Harry Wentland wrote:
> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> > On Fri, 9 Jul 2021 18:23:26 +0200
> > Raphael Gallais-Pou wrote:
> >
> >> On 7/9/21 10:04 AM, Pekka Paalanen wrote:
> >>> On Wed, 7 Jul 2021 08:48:47 +
> >>> Raphael GALLAIS-POU
Hello Benjamin,
The HDMI TX block in the RK3568 requires two power supplies, which have
to be enabled in some cases (at least on the RK3568 EVB1 the voltages
VDDA0V9_IMAGE and VCCA1V8_IMAGE are disabled by default). It would be
great if this was considered by the driver and the device tree binding
Hi Dave and Daniel,
these two fixes in drm-misc-fixes got lost during last cycle. Sending them
now.
Best regards
Thomas
drm-misc-fixes-2021-07-13:
Short summary of fixes pull:
* dma-buf: Fix fence leak in sync_file_merge() error code
* drm/panel: nt35510: Don't fail on DSI reads
The following
Hi Michael,
Am Dienstag, 13. Juli 2021, 10:44:00 CEST schrieb Michael Riesch:
> The HDMI TX block in the RK3568 requires two power supplies, which have
> to be enabled in some cases (at least on the RK3568 EVB1 the voltages
> VDDA0V9_IMAGE and VCCA1V8_IMAGE are disabled by default). It would be
>
On 12/07/2021 17:12, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 04:51:42PM +0100, Tvrtko Ursulin wrote:
On 12/07/2021 15:42, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later pa
On 24.06.2021 09:04, Matthew Brost wrote:
> Update GuC debugfs to support the new GuC structures.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
> ..
Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
broke severla IGT tests in vgem_basic. [1] Attempts to fix the issue
have not worked out so far. [2][3] Revert the original patch for now.
Note that there is a patch that converts vgem to shmem helpers. [4]
Merging this change
On 24/06/2021 08:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
and ring tail value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submis
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
> Am 13.07.21 um 08:50 schrieb Daniel Vetter:
> > On Tue, Jul 13, 2021 at 8:35 AM Christian König
> > wrote:
> >> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> >>> It might be good enough on x86 with just READ_ONCE, but the write side
> >>> s
Ping for any reviewers? This fixes a customer issue on heavily loaded
transcode boxes by avoiding false GPU hang reports upon pressing Ctrl-C.
Regards,
Tvrtko
On 16/06/2021 11:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banne
On 6/29/21 9:04 PM, Abhinav Kumar wrote:
During board bringups its useful to have a DSI test pattern
generator to isolate a DPU vs a DSI issue and focus on the relevant
hardware block.
To facilitate this, add an API which triggers the DSI controller
test pattern. The expected output is a rect
On 2021-07-07 13:03, Benjamin Gaignard wrote:
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Do you know what hclk_vio is and whether it's actually necessary? I
don't see any mention of it dow
Before we can pull in the previous kernel doc for the caching bits, we
first get to add kernel doc for all of drm_i915_gem_object so this
actually builds.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 422 +++---
1 file changed, 36
EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
possible for userspace to bypass the GTT caching bits set by the kernel,
as per the given object cache_level. This is troublesome since the heavy
flush we apply when first acquiring the pages is skipped if the kernel
thinks the objec
Try to document the object caching related bits, like cache_coherent and
cache_dirty.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 135 +-
drivers/gpu/drm/i915/i915_drv.h | 9 --
2 files changed, 131
Add some kernel doc for this. We can then just reference this later when
documenting madv in the kernel.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 50 +++--
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/inclu
Pull in the kernel-doc for drm_i915_gem_object.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
Documentation/gpu/i915.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 204ebdaadb45..77558084e989 100644
--- a/Documenta
On Mon, Jul 12, 2021 at 4:37 PM Daniel Vetter wrote:
> On Mon, Jul 12, 2021 at 04:55:44PM +0800, Zhen Lei wrote:
> > The execution of fb_delete_videomode() is not based on the result of the
> > previous fbcon_mode_deleted(). As a result, the mode is directly deleted,
> > regardless of whether it i
Am 13.07.21 um 11:10 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONC
Matthew Auld writes:
> Try to document the object caching related bits, like cache_coherent and
> cache_dirty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 135 +-
> drivers/gpu/drm/i915/i915_drv.h
We skip filling out the pt with scratch entries if the va range covers
the entire pt, since we later have to fill it with the PTEs for the
object pages anyway. However this might leave open a small window where
the PTEs don't point to anything valid for the HW to consume.
When for example using 2M
Am 09.07.21 um 10:11 schrieb Daniel Vetter:
We kinda left this out, and I like the wording from the drm-intel
side, so add that. Motivated by a discussion with Christian.
I always thought this goes without saying.
Cc: Christian König
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zi
On Tue, Jul 13, 2021 at 3:09 AM Salah Triki wrote:
>
> Use swap() instead of implementing it since it makes code more clean.
>
> Signed-off-by: Salah Triki
Patches for this driver generally have the following prefix in the subject:
gpu: ipu-v3:
Alex
> ---
> drivers/gpu/ipu-v3/ipu-image-conver
Use swap() instead of implementing it since it makes code more clean.
Signed-off-by: Salah Triki
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gpu/ipu-v3/ipu-image-convert.c
On Tue, Jul 13, 2021 at 02:04:31PM +0100, Matthew Auld wrote:
> We skip filling out the pt with scratch entries if the va range covers
> the entire pt, since we later have to fill it with the PTEs for the
> object pages anyway. However this might leave open a small window where
> the PTEs don't poi
Hi,
On Mon, Jul 12, 2021 at 8:02 AM Douglas Anderson wrote:
>
> We were getting a depmod error:
> depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
>
> It looks like the rule is that drm_kms_helper can call into drm, but
> drm can't call into drm_kms_helper. That means we'v
On Thu, Jun 03, 2021 at 11:08:31PM +0200, Daniel Vetter wrote:
> We want to stop gup, which isn't the case if we use vmf_insert_page
> and VM_MIXEDMAP, because that does not set pte_special.
>
> v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
>
> v3: add more depends on MMU.
On Tue, Jul 13, 2021 at 10:44:05AM +0200, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> these two fixes in drm-misc-fixes got lost during last cycle. Sending them
> now.
Applied to drm-fixes, thanks.
-Daniel
>
> Best regards
> Thomas
>
> drm-misc-fixes-2021-07-13:
> Short summary of fixes
Hi Salah,
On Tue, Jul 13, 2021 at 10:33 AM Salah Triki wrote:
>
> Use swap() instead of implementing it since it makes code more clean.
s/more clean/cleaner
> Signed-off-by: Salah Triki
> ---
> drivers/gpu/ipu-v3/ipu-image-convert.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(
On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
> On Mon, 12 Jul 2021 12:15:59 -0400
> Harry Wentland wrote:
>
>> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
>>> On Fri, 9 Jul 2021 18:23:26 +0200
>>> Raphael Gallais-Pou wrote:
>>>
On 7/9/21 10:04 AM, Pekka Paalanen wrote:
> On
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up already.
v2: I realized that this is fundamentally b
Use swap() instead of implementing it since it makes code cleaner.
Signed-off-by: Salah Triki
---
Changes since v1:
- Remove the declaration of tmp
- Fix typo in the description
drivers/gpu/ipu-v3/ipu-image-convert.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-
Hi,
In the display core, we utilize floats and doubles units for calculating
modesetting parameters. One side effect of our approach to use double-precision
is the fact that we spread multiple FPU access across our driver, which means
that we can accidentally clobber user space FPU state.
# Chall
The display core files rely on FPU operation, which requires to be
compiled with special flags. Ideally, we don't want these FPU operations
spread around the DC code; nevertheless, it happens in the current
source. This commit introduces a new directory named fpu_operations that
intends to centrali
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mechanism inside our DC_FP_START/END macros for
trying to alleviate this problem.
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/
To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface from other files, the compiler
might enable the use
DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the access to
kernel_fpu_begin/end.
Change since V1:
On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> From: 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
> dma_buf_map_attachment(). But the exporter also locks the
On Tue, Jul 13, 2021 at 9:40 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> > From: 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 d
On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> From: Thomas Hellström
>
> Until we support p2p dma or as a complement to that, migrate data
> to system memory at dma-buf attach time if possible.
>
> v2:
> - Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
>
On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> > From: Thomas Hellström
> >
> > Until we support p2p dma or as a complement to that, migrate data
> > to system memory at dma-buf attach time if possible.
> >
> > v2:
> > - Re
On Tue, Jul 13, 2021 at 04:06:13PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
> >
> > On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> > > From: Thomas Hellström
> > >
> > > Until we support p2p dma or as a complement to that, migrate data
> >
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
>
>
>
> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
> > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > is_cow_mapping returns true for these mappings. Add a check for
> > vm_flags & VM_WRITE to avoid mmap failures on priva
Am 2021-07-13 um 2:57 a.m. schrieb Christian König:
>
>
> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
>> is_cow_mapping returns true for these mappings. Add a check for
>> vm_flags & VM_WRITE to avoid mmap failures on private read-o
On Fri, Jun 4, 2021 at 8:34 AM Linus Walleij wrote:
> Remove interrupt disablement during backlight setting. It is
> way to dangerous and makes platforms instable by having it
> miss vblank IRQs leading to the graphics derailing.
>
> The code is using ndelay() which is not available on
> platform
add fixes to pass DP Link Layer compliance test cases
Kuogee Hsieh (7):
drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run
drm/msm/dp: reduce link rate if failed at link training 1
drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed.
drm/msm/dp: replug ev
DP cable should always connect to DPU during the entire PHY compliance
testing run. Since DP PHY compliance test is executed at irq_hpd event
context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off().
dp_ctrl_off() is used for unplug event which is triggered when DP cable is
dis co
Reduce link rate and re start link training if link training 1
failed due to loss of clock recovery done to fix Link Layer
CTS case 4.3.1.7. Also only update voltage and pre-emphasis
swing level after link training started to fix Link Layer CTS
case 4.3.1.6.
Changes in V2:
-- replaced cr_status w
Remove special handling of replug interrupt and instead treat replug event
as a sequential unplug followed by a plugin event. This is needed to meet
the requirements of DP Link Layer CTS test case 4.2.1.3.
Changes in V2:
-- add fixes statement
Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with
Aux hardware calibration sequence requires resetting the aux controller
in order for the new setting to take effect. However resetting the AUX
controller will also clear HPD interrupt status which may accidentally
cause pending unplug interrupt to get lost. Therefore reset aux
controller only when
Response with correct edid checksum saved at connector after corrupted edid
checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_panel.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
Initialize both pre-emphasis and voltage swing level to 0 before
start link training and do not end link training until video is
ready to reduce the period between end of link training and video
start to meet Link Layer CTS requirement. This fixes Link Layer
CTS cases 4.3.2.1, 4.3.2.2, 4.3.2.3 and
Main link symbol locked is achieved at end of link training 2. Some
dongle main link symbol may become unlocked again if host did not end
link training soon enough after completion of link training 2. Host
have to re train main link if loss of symbol lock detected before
end link training so that t
On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> + /**
> + * @cache_coherent:
> + *
> + * Track whether the pages are coherent with the GPU if reading or
> + * writing through the CPU cache.
> + *
> + * This largely depends on the @cache_level, for e
On 2021-07-13 5:10 a.m., Daniel Vetter wrote:
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ
On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
wrote:
>
> On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > + /**
> > + * @cache_coherent:
> > + *
> > + * Track whether the pages are coherent with the GPU if reading or
> > + * writing through the CPU cache.
> >
On 12/07/2021 22:55, Laurent Pinchart wrote:
> Hi Steven,
Hi Laurent,
> On Mon, Jul 12, 2021 at 10:31:52PM +0100, Steven Price wrote:
>> On 12/07/2021 17:50, Laurent Pinchart wrote:
>>> On Mon, Jul 12, 2021 at 04:57:58PM +0100, Steven Price wrote:
When bailing out due to the sanity check the
https://bugzilla.kernel.org/show_bug.cgi?id=213715
Bug ID: 213715
Summary: failed to change brightness of HDR panel on AMD
GREEN_SARDINE through aux
Product: Drivers
Version: 2.5
Kernel Version: 5.14.0-rc1+
Hardware: Al
https://bugzilla.kernel.org/show_bug.cgi?id=213715
--- Comment #1 from Pengyu Ma (mapen...@gmail.com) ---
Created attachment 297821
--> https://bugzilla.kernel.org/attachment.cgi?id=297821&action=edit
4k display edid
--
You may reply to this email to add a comment.
You are receiving this mail
Hi Benjamin,
Am 07.07.21 um 14:03 schrieb Benjamin Gaignard:
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
This version of the HDMI hardware block need two clocks to provide
phy reference clock: hclk_vio and hclk.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Add the cl
The user can pass in any value to the driver through the 'ioctl'
interface. The driver dost not check, which may cause DoS bugs.
Fix this by checking if the divisor is 0
The following log reveals it:
divide error: [#1] PREEMPT SMP KASAN PTI
RIP: 0010:SetOverlayViewPort+0x133/0x5f0
drivers/
The driver uses a conservative set of hardcoded values for the
maximum time delay of the transitions between LP and HS, either
for data and clock lanes.
By using the info in STM32MP157 datasheet, valid also for other ST
devices, compute the actual delay from the lane's bps.
Signed-off-by: Antonio
On Tue, Jun 29, 2021 at 12:04 PM Abhinav Kumar wrote:
>
> During board bringups its useful to have a DSI test pattern
> generator to isolate a DPU vs a DSI issue and focus on the relevant
> hardware block.
>
> To facilitate this, add an API which triggers the DSI controller
> test pattern. The exp
Hi Jagan,
On 7/4/21 3:59 PM, Jagan Teki wrote:
As dw-mipi-dsi supported all possible ways to find the DSI
devices. It can take multiple iterations for ltdc to find
all components attached to the DSI bridge.
The current ltdc driver failed to find the endpoint as
it returned -EINVAL for the first
On Tue, Jul 13, 2021 at 6:11 PM Andrey Grodzovsky
wrote:
> On 2021-07-13 5:10 a.m., Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 9:25 AM Christian König
> > wrote:
> >> Am 13.07.21 um 08:50 schrieb Daniel Vetter:
> >>> On Tue, Jul 13, 2021 at 8:35 AM Christian König
> >>> wrote:
> Am 12
Hi Antonio,
On 7/13/21 4:49 PM, Antonio Borneo wrote:
The driver uses a conservative set of hardcoded values for the
maximum time delay of the transitions between LP and HS, either
for data and clock lanes.
By using the info in STM32MP157 datasheet, valid also for other ST
devices, compute the
On Tue, Jul 13, 2021 at 6:14 PM Matthew Auld
wrote:
> On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > + /**
> > > + * @cache_coherent:
> > > + *
> > > + * Track whether the pages are coherent with
On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter wrote:
>
> There's only one exclusive slot, and we must not break the ordering.
>
> Adding a new exclusive fence drops all previous fences from the
> dma_resv. To avoid violating the signalling order we err on the side of
> over-synchronizing by waitin
On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
>
> On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter wrote:
> >
> > There's only one exclusive slot, and we must not break the ordering.
> >
> > Adding a new exclusive fence drops all previous fences from the
> > dma_resv. To avoid violating the signa
On 6/25/21 3:09 PM, Javier Martinez Canillas wrote:
> The simplefb and simpledrm drivers match against a "simple-framebuffer"
> device, but for aarch64 this is only registered when using Device Trees
> and there's a node with a "simple-framebuffer" compatible string.
>
> There is no code to regist
On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote:
>
> On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
> >
> > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter
> > wrote:
> > >
> > > There's only one exclusive slot, and we must not break the ordering.
> > >
> > > Adding a new exclusive fence dr
On Tue, Jul 13, 2021 at 7:14 PM Grace An wrote:
> When CONFIG_PROVE_LOCKING is defined, the kernel randomly injects
> -EDEADLK errors for all the ww_mutex. This results in
> drm_atomic_get_private_obj_state randomly returning -EDEADLK.
> However, the mode_fixup functions do not propagate these err
On Tue, Jul 13, 2021 at 7:42 PM Rob Clark wrote:
> On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote:
> >
> > On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
> > >
> > > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter
> > > wrote:
> > > >
> > > > There's only one exclusive slot, and we must n
On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > + /**
> > > + * @cache_coherent:
> > > + *
> > > + * Track whether the pages are coher
On Monday, July 5, 2021 6:53:08 AM PDT Matthew Auld wrote:
> It's a noop on DG1, and in the future when need to support other devices
> which let us control the coherency, then it should be an immutable
> creation time property for the BO. This will likely be controlled
> through a new gem_create_e
On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
wrote:
>
> On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> > On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > > + /**
> > > > + * @cache_coher
On 6/24/2021 00:04, Matthew Brost wrote:
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++-
d
On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> > > On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Jul 13, 2021 at 11:45:5
The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
in backlight.c") says that gpio-backlight uses brightness as power state.
This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
Correct initial power state handling") and other backlight drivers do not
requ
Make it obvious that mode_fixup is deprecated and new drivers shall use
atomic_check.
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/drm_bridge.h | 3 +++
1
On Tue, Jul 13, 2021 at 07:44:12PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 7:14 PM Grace An wrote:
> > When CONFIG_PROVE_LOCKING is defined, the kernel randomly injects
> > -EDEADLK errors for all the ww_mutex. This results in
> > drm_atomic_get_private_obj_state randomly returning -
Hi
On Tue, Jul 13, 2021 at 12:51:14PM +, Zheyu Ma wrote:
> The user can pass in any value to the driver through the 'ioctl'
> interface. The driver dost not check, which may cause DoS bugs.
>
> Fix this by checking if the divisor is 0
This fix is trying to avoid the situation on a too low la
On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
wrote:
> Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The conversion to ww mutexes failed to address the fence code which
> > already returns -EDEADLK when we run out of fences. Ww mutexes on
> > the other hand trea
On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
>
> On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> wrote:
> > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The conversion to ww mutexes failed to address the fence code which
> > > already returns -ED
On Tue, Jul 13, 2021 at 9:33 PM Sam Ravnborg wrote:
>
> Make it obvious that mode_fixup is deprecated and new drivers shall use
> atomic_check.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Andrzej Hajda
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc:
On Tue, Jul 13, 2021 at 09:59:18PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
> >
> > On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> > wrote:
> > > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > > From: Ville Syrjälä
> > > >
> > > > The conversion
Hi Daniel,
On Tue, Jul 13, 2021 at 03:59:22PM +0200, Daniel Vetter wrote:
> Some vague evidences suggests this can go wrong. Try to prevent it by
> holding the right mutex and clearing ->deferred_setup to make sure we
> later on don't accidentally try to re-register the fbdev when the
> driver tho
On Fri, Jul 9, 2021 at 10:11 AM Daniel Vetter wrote:
>
> We kinda left this out, and I like the wording from the drm-intel
> side, so add that. Motivated by a discussion with Christian.
>
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Signed-off-by:
On Tue, Jul 13, 2021 at 09:59:18PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
> >
> > On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> > wrote:
> > > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > > From: Ville Syrjälä
> > > >
> > > > The conversion
Hi all
I've found another potential issue, so lets try this again and see what
intel-gfx-ci says. Also Thomas tried to unify vgem more, which motivated
me to dig this all out again.
Test-with: 20210527140732.5762-1-daniel.vet...@ffwll.ch
Review very much welcome, as always!
Cheers, Daniel
Dani
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
v3: add more depends on MMU. For usb drivers this is a bit awkward,
but really it's correct: To be able
intel-gfx-ci realized that something is not quite coherent anymore on
some platforms for our i915+vgem tests, when I tried to switch vgem
over to shmem helpers.
After lots of head-scratching I realized that I've removed calls to
drm_clflush. And we need those. To make this a bit cleaner use the
sa
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident sys
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking a
1 - 100 of 116 matches
Mail list logo
