On Tue, Sep 27, 2022 at 11:27 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 26, 2022 at 11:35 PM Sean Hong
> wrote:
> >
> > Add support for the BOE - NT116WHM-N4C (HW: V8.1) panel.
> >
> > Signed-off-by: Sean Hong
> > ---
> > drivers/gpu/drm/panel/panel-edp.c | 1 +
> > 1 file changed, 1 inse
fbtft_probe_common() allocates a memory chunk for "info" with
fbtft_framebuffer_alloc(). When "display->buswidth == 0" is true, the
function returns without releasing the "info", which will lead to a
memory leak.
Fix it by calling fbtft_framebuffer_release() when "display->buswidth
== 0" is true.
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.
Fix this by only freeing spt in ppgtt_invalidate_spt in good case.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge
Den 26.09.2022 kl. 12.30 skrev Michael Riesch:
Hi Sascha,
On 9/26/22 10:04, Sascha Hauer wrote:
This series adds support for 4k@30 to the rockchip HDMI controller. This
has been tested on a rk3568 rock3a board. It should be possible to add
4k@60 support the same way, but it doesn't work for m
Hi,
thank you for your information.
On our website you can find email addresses of companies and people.
https://www.skymem.info
In short, it’s like Google for emails.
Best regards,
Robert,
Skymem team
On Tue, Sep 27, 2022 at 8:46 PM Stefan Wahren wrote:
>
> Hi Maxime,
>
> Am 27.09.22 um 15:15
From: ye xingchen
Replace the open-code with sysfs_emit() to simplify the code.
Signed-off-by: ye xingchen
---
v1 -> v2
Add the rest of this fixes for this pattern in the 'drivers/video/backlight'
directory.
drivers/video/backlight/lm3533_bl.c | 10 +-
drivers/video/backlight/lp855x_b
Add support for handling out fence for vm_bind call.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 81 +++
drivers/gpu/drm/i915/i915_vma.c
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 16 +++-
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 6
Do not use i915_vma activeness tracking for persistent vmas.
As persistent vmas are part of working set for each execbuf
submission on that address space (VM), a persistent vma is
active if the VM active. As vm->root_obj->base.resv will be
updated for each submission on that VM, it correctly
repre
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 99 +++
drivers/
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Abstract out the common execbuf functionalities into a
separate file where possible, thus allowing code sharing.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 19 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace befor
Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 188 +-
1 file changed, 187 insertions(+), 1 deletion(-)
diff --git a/
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 512 ++
1 file changed, 38 insertions(+), 474 deletions(-)
diff --git a/d
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_sw_fence.c | 28 +---
driv
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.
VM private BOs can be o
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing. ie., multiple
mappings (at different VA) point to the same
Make i915_gem_vm_lookup() function non-static as it will be
used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
2 files changed, 13
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs at specified GPU virtual
addresses on a specified address space (VM). Multiple mappings can map
to the same physical pages of an object (aliasing). These mappings (also
referred to as persiste
On 28-09-2022 03:52, Matt Roper wrote:
> On Tue, Sep 27, 2022 at 12:14:24AM +0530, Aravind Iddamsetty wrote:
>> As an integrated GPU, MTL does not have local memory and
>> HAS_LMEM() returns false. However the platform's stolen memory
>> is presented via BAR2 (i.e., the BAR we traditionally con
On 9/28/22 03:54, Laurent Pinchart wrote:
Hi Marek,
Hi,
+ /*
+* The CSC differentiates between "YCbCr" and "YUV", but the reference
+* manual doesn't detail how they differ. Experiments showed that the
+* luminance value is unaffected, only the calculations invol
Hey, i have problems with my git-send today so i just attached V5 as a
patch here.
Andrey
On 2022-09-27 19:56, Luben Tuikov wrote:
Inlined:
On 2022-09-22 12:15, Andrey Grodzovsky wrote:
On 2022-09-22 11:03, Luben Tuikov wrote:
The title of this patch has "v3", but "v4" in the title prefix.
On Tue, 2022-09-27 at 06:23 -0700, Guillaume Ranquet wrote:
> On Tue, 20 Sep 2022 09:46, Chunfeng Yun
> wrote:
> > On Mon, 2022-09-19 at 18:56 +0200, Guillaume Ranquet wrote:
> > > Add basic support for the mediatek hdmi phy on MT8195 SoC
> > >
> > > Signed-off-by: Guillaume Ranquet
> > >
> > >
Hi Marek,
On Wed, Sep 28, 2022 at 03:09:11AM +0200, Marek Vasut wrote:
> On 9/28/22 02:58, Laurent Pinchart wrote:
>
> [...]
>
> > + /*
> > +* The CSC differentiates between "YCbCr" and "YUV", but the reference
> > +* manual doesn't detail how they differ. Experiments showed that the
>
On Tue, 27 Sep 2022 04:35:29 -0700, Badal Nilawar wrote:
>
> From: Don Hiatt
>
> On GEN12 and above use GEN12_RPSTAT register to get Current
> Actual Graphics Frequency of GT
I think even for the purposes of reviewing this it would be good to mention
in the commit message that:
a. GEN12_RPSTAT r
On 9/28/22 02:58, Laurent Pinchart wrote:
[...]
+ /*
+* The CSC differentiates between "YCbCr" and "YUV", but the reference
+* manual doesn't detail how they differ. Experiments showed that the
+* luminance value is unaffected, only the calculations involving chrom
On 9/28/22 02:58, Laurent Pinchart wrote:
Up to and including v1.3, HDMI supported limited quantization range only
for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
features isn't supported in the dw-hdmi driver that is used in
conjunction with the LCDIF in the i.MX8MP. The
On 9/28/22 02:58, Laurent Pinchart wrote:
The BIT() macro is meant to represent a single bit. Don't use it for
values of register fields that span multiple bits.
Signed-off-by: Laurent Pinchart
Reviewed-by: Marek Vasut
From: Kieran Bingham
The LCDIF includes a color space converter that supports YUV input. Use
it to support YUV planes, either through the converter if the output
format is RGB, or in conversion bypass mode otherwise.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes sin
The BIT() macro is meant to represent a single bit. Don't use it for
values of register fields that span multiple bits.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Use hex for field values
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 28 ++--
1 file changed, 14 i
Up to and including v1.3, HDMI supported limited quantization range only
for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
features isn't supported in the dw-hdmi driver that is used in
conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus
always advertised
A couple of the register macro values are incorrectly indented. Fix
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Marek Vasut
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h
b/drivers/gpu/drm
Hello,
This small patch series improves YUV support in the i.MX8MP LCDIF
driver. After patches 1/4 and 2/4 that fix tiny cosmetic issues, patch
3/4 fixes YUV quantization range for the RGB to YUV conversion. Patch
4/4 addresses the other direction and adds support for YUV planes.
Please see indiv
On 9/28/22 02:40, Laurent Pinchart wrote:
On Wed, Sep 28, 2022 at 02:37:04AM +0200, Marek Vasut wrote:
On 9/28/22 02:21, Laurent Pinchart wrote:
Hi,
[...]
- /* CSC: BT.601 Full Range RGB to YCbCr coefficients. */
- writel(CSC0_COEF0_A2(0x096) | CSC0_COEF0_A1(0x04c
On Wed, Sep 28, 2022 at 02:37:04AM +0200, Marek Vasut wrote:
> On 9/28/22 02:21, Laurent Pinchart wrote:
>
> Hi,
>
> [...]
>
> >>> - /* CSC: BT.601 Full Range RGB to YCbCr coefficients. */
> >>> - writel(CSC0_COEF0_A2(0x096) | CSC0_COEF0_A1(0x04c),
> >>> + /* CSC: BT.601
On 9/28/22 02:21, Laurent Pinchart wrote:
Hi,
[...]
- /* CSC: BT.601 Full Range RGB to YCbCr coefficients. */
- writel(CSC0_COEF0_A2(0x096) | CSC0_COEF0_A1(0x04c),
+ /* CSC: BT.601 Limited Range RGB to YCbCr coefficients. */
+ writel(CSC0
On 9/27/2022 5:10 PM, Matt Roper wrote:
On Thu, Sep 22, 2022 at 03:11:17PM -0700, Daniele Ceraolo Spurio wrote:
The render and media GuCs share the same interrupt enable register, so
we can no longer disable interrupts when we disable communication for
one of the GuCs as this would impact the
On Wed, Sep 28, 2022 at 02:16:54AM +0200, Marek Vasut wrote:
> On 9/28/22 01:38, Laurent Pinchart wrote:
>
> Hi,
>
> [...]
>
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index ba84b51598b3..a97a5f512aae 100644
> > --- a/drivers/gpu/drm/mxsfb/lcd
Hi Marek,
On Wed, Sep 28, 2022 at 02:12:19AM +0200, Marek Vasut wrote:
> On 9/28/22 01:38, Laurent Pinchart wrote:
> > Up to and including v1.3, HDMI supported limited quantization range only
> > for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
> > features isn't supported
Hi Marek,
On Wed, Sep 28, 2022 at 02:10:26AM +0200, Marek Vasut wrote:
> On 9/28/22 01:38, Laurent Pinchart wrote:
> > The BIT() macro is meant to represent a single bit. Don't use it for
> > values of register fields that span multiple bits.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
On 9/28/22 01:38, Laurent Pinchart wrote:
Hi,
[...]
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index ba84b51598b3..a97a5f512aae 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
[...]
@@ -37,9 +38,10 @@ static vo
On 9/28/22 01:38, Laurent Pinchart wrote:
Up to and including v1.3, HDMI supported limited quantization range only
for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
features isn't supported in the dw-hdmi driver that is used in
conjunction with the LCDIF in the i.MX8MP. The
On Thu, Sep 22, 2022 at 03:11:17PM -0700, Daniele Ceraolo Spurio wrote:
> The render and media GuCs share the same interrupt enable register, so
> we can no longer disable interrupts when we disable communication for
> one of the GuCs as this would impact the other GuC. Instead, we keep the
> inter
On 9/28/22 01:38, Laurent Pinchart wrote:
The BIT() macro is meant to represent a single bit. Don't use it for
values of register fields that span multiple bits.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 28 ++--
1 file changed, 14 inser
On 9/28/22 01:38, Laurent Pinchart wrote:
A couple of the register macro values are incorrectly indented. Fix
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Marek Vasut
Inlined:
On 2022-09-22 12:15, Andrey Grodzovsky wrote:
>
> On 2022-09-22 11:03, Luben Tuikov wrote:
>> The title of this patch has "v3", but "v4" in the title prefix.
>> If you're using "-v" to git-format-patch, please remove the "v3" from the
>> title.
>>
>> Inlined:
>>
>> On 2022-09-21 14:28,
DRM commit_tails() will disable downstream crtc/encoder/bridge if
both disable crtc is required and crtc->active is set before pushing
a new frame downstream.
There is a rare case that user space display manager issue an extra
screen update immediately followed by close DRM device while down
strea
From: Kieran Bingham
The LCDIF includes a color space converter that supports YUV input. Use
it to support YUV planes, either through the converter if the output
format is RGB, or in conversion bypass mode otherwise. For now only
BT.601 YCbCr encoding in limited quantization range is supported,
a
Up to and including v1.3, HDMI supported limited quantization range only
for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
features isn't supported in the dw-hdmi driver that is used in
conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus
always advertised
The BIT() macro is meant to represent a single bit. Don't use it for
values of register fields that span multiple bits.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/driver
A couple of the register macro values are incorrectly indented. Fix
them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h
b/drivers/gpu/drm/mxsfb/lcdif_regs.h
index
Hello,
This small patch series improves YUV support in the i.MX8MP LCDIF
driver. After patches 1/4 and 2/4 that fix tiny cosmetic issues, patch
3/4 fixes YUV quantization range for the RGB to YUV conversion. Patch
4/4 addresses the other direction and adds support for YUV planes.
Please see indiv
On Tue, Sep 20, 2022 at 07:24:54AM +0200, Mauro Carvalho Chehab wrote:
> Hi Luis,
>
> On Mon, 9 May 2022 13:38:28 -0700
> Luis Chamberlain wrote:
>
> > On Mon, May 09, 2022 at 06:23:35PM +0200, Mauro Carvalho Chehab wrote:
> > > Currently, kernel/module annotates module dependencies when
> > > r
Properties describing GPIOs should be named as "-gpios" or
"-gpio", and that is what gpiod API expects, however the
driver uses non-standard "gpios-reset" name. Let's adjust this, and also
note that the reset line is active low as that is also important to
gpiod API.
Signed-off-by: Dmitry Torokhov
On Tue, Sep 27, 2022 at 12:14:24AM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and
> HAS_LMEM() returns false. However the platform's stolen memory
> is presented via BAR2 (i.e., the BAR we traditionally consider
> to be the LMEM BAR) and should be manag
The drm_test_dp_mst_sideband_msg_req_decode repeats the same test
structure with different parameters. This could be better represented
by parameterized tests, provided by KUnit.
In order to convert the tests to parameterized tests, the test case for
the client ID was changed: instead of using get
The drm_test_dp_mst_calc_pbn_mode is based on a loop that executes tests
for a couple of test cases. This could be better represented by
parameterized tests, provided by KUnit.
So, convert the drm_test_dp_mst_calc_pbn_mode into parameterized tests.
Signed-off-by: Maíra Canal
Reviewed-by: Michał
On Fri, Sep 16, 2022 at 01:48:23PM -0700, Ashutosh Dixit wrote:
> From: Chris Wilson
>
> If attempting to perform a GT reset takes long than 5 seconds (including
> resetting the display for gen3/4), then we declare all hope lost and
> discard all user work and wedge the device to prevent furthe
[AMD Official Use Only - General]
Reviewed-by: Aurabindo Pillai
--
Regards,
Jay
From: Mahfooz, Hamza
Sent: Tuesday, September 27, 2022 3:12 PM
To: linux-ker...@vger.kernel.org
Cc: Mahfooz, Hamza ; Wentland, Harry
; Li, Sun peng (Leo) ; Siqueira,
Rodrigo ; De
Address the following error:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function
‘dc_stream_remove_writeback’:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:55: error: array
subscript [0, 0] is outside array bounds of ‘struct dc_writeback_info[1]’
[-Werror=arra
On Tue, 2022-09-13 at 16:22 -0700, Ceraolo Spurio, Daniele wrote:
> Wait on the fence to be signalled to avoid the submissions finding HuC
> not yet loaded.
>
> v2: use dedicaded wait_queue_entry for waiting in HuC load, as submitq
> can't be re-used for it.
>
> Signed-off-by: Daniele Ceraolo S
On 9/27/2022 12:16 AM, Johan Hovold wrote:
On Mon, Sep 26, 2022 at 11:21:38AM -0700, Abhinav Kumar wrote:
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Drop the overly defensive modeset sanity checks of function parameters
which have already been checked or used by the callers.
Reviewed-by: D
Hi Maxime,
Am 27.09.22 um 15:15 schrieb Maxime Ripard:
On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote:
On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote:
On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote:
Am 27.09.22 um 11:42 schrieb Maxime Ripard:
On T
On 9/27/2022 12:14 AM, Johan Hovold wrote:
On Mon, Sep 26, 2022 at 11:17:20AM -0700, Abhinav Kumar wrote:
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Drop the overly defensive modeset sanity checks of function parameters
which have already been checked or used by the callers.
Reviewed-by: Dmi
virtio-gpu host(e.g. QEMU) deletes all virtio-gpu resourses when guest
is suspended then resumed. This behavior is invisible to the guest. As
a result, the guest can send out virtio-gpu commands for those deleted
resources with an assumption they are still there on host's side when
the guest wakes
virtqueue needs to be flushed and removed before VM goes into sleep or
hibernation then should be reinitialized again upon wake-up.
Cc: Gerd Hoffmann
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 53 +++-
drivers/gpu/drm/virti
This series is for adding virtio-gpu driver the support for the suspend and
resume
(or freeze and restore).
First patch adds virtio-dev hooks that adds .freeze and .restore hooks that
basically
flush and remove virtqueue before going into suspension then reinitialize them
upon
wake-up event.
S
On Fri, Aug 19, 2022 at 01:48:37AM +0530, Akhil P Oommen wrote:
> Add a reset op compatible function to poll for gdsc collapse.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Minor update to function prototype
>
> drivers/clk/qcom/gdsc.c | 23
Remove the extra signaled bit status check because
it is returning early when the fence is already signaled and
__dma_fence_enable_signaling is checking the status of signaled
bit again.
Signed-off-by: Arvind Yadav
---
drivers/dma-buf/dma-fence.c | 5 -
1 file changed, 5 deletions(-)
diff -
Here's enabling software signaling on fence for sw_sync.
Signed-off-by: Arvind Yadav
---
drivers/dma-buf/sw_sync.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..d2a52ceac14e 100644
--- a/drivers/dma-buf/sw_sync.c
+
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled_locked() function ever returns true.
Since drivers and implementations sometimes mess this up,
this ensures correct behaviour when DMABUF_DEBUG_ENABLE_SIGNALING
is used during debugging.
This should make any implementation
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled() and dma_fence_is_signaled_locked()
function ever returns true. Since drivers and implementations
sometimes mess this up, this ensures correct behaviour when
DEBUG_WW_MUTEX_SLOWPATH is used during debugging.
This should ma
From: Ville Syrjälä
Rename info->monitor_range to info->vrr_range to actually
reflect its usage.
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Manasi Navare
Acked-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Get rid of the confusing version_greater() stuff and
simply compare edid->revision directly everwhere. Half
the places already did it this way, and since we actually
reject any EDID with edid->version!=1 it's a perfectly
sane thing to do.
Reviewed-by: Jani Nikula
Signed-off-
From: Ville Syrjälä
Prefer the timing formula indicated by the range
descriptor for generating the non-DMT standard timings.
Previously we just used CVT for all EDID 1.4 continuous
frequency displays without even checking if the range
descriptor indicates otherwise. Now we check the range
descri
From: Ville Syrjälä
Since we only use the parsed vrefresh range to determine
if VRR should be supported we should only accept continuous
frequency displays here.
Cc: Manasi Navare
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-...@lists.freedesktop.org
Re
From: Ville Syrjälä
For some resaon we only use the secondary GTF curve for the
standard timings. Use it for inferred modes as well.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 35 ++-
1 file changed, 34 insertions(+),
From: Ville Syrjälä
Extract the GTF vs. GTF2 logic into a separate function.
We'll have a second user soon.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 47 --
1 file changed, 30 insertions(+), 17 deletions(-)
diff
From: Ville Syrjälä
For EDID 1.4 the first detailed timing is always preferred,
for older EDIDs there was a feature flag to indicate the same.
While correct, the code setting that up is rather confusing.
Restate it in a slightly more straightforward manner.
Reviewed-by: Jani Nikula
Signed-off-b
From: Ville Syrjälä
The current comment fails to clarify why we only accept
the "range limits only" variant of the range descriptor.
Reword it to make some actual sense.
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-...@lists.freedesktop.org
Reviewed-by:
From: Ville Syrjälä
Replace a bunch of hex constants with proper definitions.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 18 +-
include/drm/drm_edid.h | 14 +-
2 files changed, 18 insertions(+), 14 deletions(-)
diff
From: Ville Syrjälä
Various improvements (mostly) related to the EDID
range descriptor handling.
v2:
- One patch got merged already
- Reorder the struct rename to be last
- Drop the "infer vrr range for eDP" for now. While we may
want it eventually for now I'm just thinking of adding all
the
On some platforms we potentially have different alignment restrictions
depending on the memory type. We also now have different alignment
restrictions for the same region across different kernel versions.
Extend the region query to return the minimum required GTT alignment.
Testcase: igt@i915_quer
It turns out that on production DG2/ATS HW we should have support for
PS64. This feature allows to provide a 64K TLB hint at the PTE level,
which is a lot more flexible than the current method of enabling 64K GTT
pages for the entire page-table, since that leads to all kinds of
annoying restriction
On Tue, Sep 27, 2022 at 10:28:03AM +0100, Tvrtko Ursulin wrote:
On 26/09/2022 18:09, Niranjana Vishwanathapura wrote:
On Mon, Sep 26, 2022 at 05:26:12PM +0100, Tvrtko Ursulin wrote:
On 24/09/2022 05:30, Niranjana Vishwanathapura wrote:
On Fri, Sep 23, 2022 at 09:40:20AM +0100, Tvrtko Ursulin
Hi
Am 23.09.22 um 09:14 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann wrote:
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for t
1. Add mt8195 driver data with compatible "mediatek-mt8195-vdosys0".
2. Add mt8195 routing table settings of vdosys0.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 370
drivers/soc/mediatek/mtk-mmsys.c| 11 +
2 files changed, 381 insertio
This reverts commit 7266e90a51a32722a94daa3cb5b8fa278059e49e.
Due to the compatible changing of mt8195 from "mediatek,mt8195-mmsys"
to "mediatek,mt8195-vdosys0", we have to revert this patch and send a
new patch with the new compatible.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/m
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drive
Add driver data of mt8195 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/media
This reverts commit b804923b7ccb9c9629703364e927b48cd02a9254.
Due to the compatible changing of mt8195 from "mediatek,mt8195-mmsys"
to "mediatek,mt8195-vdosys0", we have to revert this patch and send a
new patch with the new compatible.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mt819
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drive
After mmsys and drm change DITHER enum to DDP_COMPONENT_DITHER0,
mmsys header can remove the useless DDP_COMPONENT_DITHER enum.
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rex-BC Chen
Acked-by: Matthias Brugger
---
include/linux/soc/mediatek/mtk-mmsys.h |
Hi,
On Mon, Sep 26, 2022 at 11:35 PM Sean Hong
wrote:
>
> Add support for the BOE - NT116WHM-N4C (HW: V8.1) panel.
>
> Signed-off-by: Sean Hong
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
Wow, another panel?!?
Reviewed-by: Douglas Anderson
Pushed to drm
On Sat, Sep 24, 2022 at 09:27:10PM +0300, Dmitry Baryshkov wrote:
> Hi,
>
> On Sat, 24 Sept 2022 at 20:23, Krzysztof Kozlowski
> wrote:
> >
> > On Sat, 24 Sep 2022 15:36:00 +0300, Dmitry Baryshkov wrote:
> > > Split Mobile Display SubSystem (MDSS) root node bindings to the separate
> > > yaml fil
On 9/8/2022 10:44 AM, T.J. Mercier wrote:
On Tue, Aug 16, 2022 at 1:39 PM Jeffrey Hugo wrote:
Hello cgroup experts,
I have a GPU device [1] that supports organizing its resources for the
purposes of supporting containers. I am attempting to determine how to
represent this in the upstream ker
1 - 100 of 151 matches
Mail list logo
