On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
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
On Tue, Jun 29, 2021 at 12:35:09PM -0700, Matthew Brost wrote:
> Subject and patches say it all.
>
> v2: Address comments, patches have details of changes
> v3: Address comments, patches have details of changes
> v4: Address comments, patches have details of changes
> v5: Fix checkpatch and docs w
On Wed, Jun 30, 2021 at 9:18 AM Desmond Cheong Zhi Xi
wrote:
>
> On 30/6/21 12:07 am, Daniel Vetter wrote:
> > On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
> >> Currently, direct copies of drm_file->master pointers should be
> >> protected by drm_device.master_mutex when
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some o
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> > 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 u
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/g
(was: drm/i915: Drop all references to DRM IRQ midlayer)
Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.
Preferably this patchset would be merged through drm-misc-next.
Thomas Zimmermann (2):
drm/i915: Use the correct IRQ during resume
drm/i915: Drop all refere
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1ca
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_drive
On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach wrote:
> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 08:12:54 +
> > Simon Ser wrote:
> >
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> >> wrote:
> >>
> >>> yes, I think this makes sense, even if it
On Wed, Jun 30, 2021 at 12:29:05PM +0800, Aaron Ma wrote:
> Hi Greg:
>
> Could this patch get a chance to be applied on stable kernel?
> It only for 5.11- kernel, not for Linus' tree.
What is the git commit id for it in Linus's tree?
And if this is not for Linus's tree, please resubmit it and do
Am 30.06.21 um 03:34 schrieb John Stultz:
This adds a shrinker controlled page pool, extracted
out of the ttm_pool logic, and abstracted out a bit
so it can be used by other non-ttm drivers.
Cc: Daniel Vetter
Cc: Christian Koenig
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laur
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin
Am 30.06.21 um 03:34 schrieb John Stultz:
After an unfortunately long pause (covid work-schedule burnout),
I wanted to revive and resubmit this series.
As before, the point of this series is trying to add both a page
pool as well as deferred-freeingto the DMA-BUF system heap to
improve alloca
On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor wrote:
>
> On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote:
> > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> > use it to determine whether to bounce the data or not. This will be
> > useful later to allow for
Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach wrote:
Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 08:12:54 +
Simon Ser wrote:
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
wrote:
yes, I think this make
Another Samsung OLED panel needs DPCD to get control of backlight.
Kernel 5.12+ support the backlight via:
commit: <4a8d79901d5b> ("drm/i915/dp: Enable Intel's HDR backlight interface
(only SDR for now)")
Only make backlight work on lower versions of kernel.
Closes: https://gitlab.freedesktop.org
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
Am 28.06.21 um 19:03 schrieb Werner Sembach:
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 app
Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.
Preferably this patchset would be merged through drm-misc-next.
v3:
* also use intel_synchronize_hardirq() from other callsite
v2:
* split patch
* also fix comment
* add intel_synchroniz
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_drive
Am 24.06.21 um 06:51 schrieb Mikel Rychliski:
radeon_ttm_bo_destroy() is attempting to access the resource object to
update memory counters. However, the resource object is already freed when
ttm calls this function via the destroy callback. This causes an oops when
a bo is freed:
BUG: k
On Tue, 29 Jun 2021, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Here goes drm-intel-next-fixes-2021-06-29:
>
> The biggest fix is the restoration of mmap ioctl for gen12 integrated parts
> which lack was breaking ADL-P with media stack.
> Besides that a small selftest fix and a theoretical over
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
> Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
> functions directly.
>
> v2:
> * also remove an outdated comment
> * move IRQ fix into separate patch
> * update Fixes tag (Daniel)
>
> S
Hi Will,
On 2021-03-25 23:03, Will Deacon wrote:
On Tue, Mar 09, 2021 at 12:10:44PM +0530, Sai Prakash Ranjan wrote:
On 2021-02-05 17:38, Sai Prakash Ranjan wrote:
> On 2021-02-04 03:16, Will Deacon wrote:
> > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > > On 2021-02-
Hi Frieder,
Thanks for sharing the details.
On Mon, Jun 28, 2021 at 1:49 PM Frieder Schrempf
wrote:
>
> Hi Jagan,
>
> On 24.06.21 10:30, Krzysztof Kozlowski wrote:
> > On 24/06/2021 04:48, Fabio Estevam wrote:
> >> Hi Jagan/Laurent,
> >>
> >> On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart
> >>
On 30/6/21 4:02 pm, Daniel Vetter wrote:
On Wed, Jun 30, 2021 at 9:18 AM Desmond Cheong Zhi Xi
wrote:
On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
Currently, direct copies of drm_file->master pointers should be
protected by
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> The code in xcs_resume() probably didn't work as intended. It uses
> struct drm_device.irq, which is allocated to 0, but never initialized
> by i915 to the device's interrupt number.
>
> v3:
> * also use intel_synchronize_h
On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
ping?
> -Original Message-
> From: dri-devel On Behalf Of Harry
> Wentland
> Sent: Monday, June 28, 2021 8:45 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash
> Subject: Re: [PATCH 04/21] drm/i915/xelpd: Define Degamma Lu
On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor wrote:
> >
> > On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote:
> > > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> > > use it to determine wheth
Hi
Am 30.06.21 um 12:06 schrieb Greg KH:
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
Having different alignment requirement by different drivers,
256B aligned should work for all drm drivers.
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/
On Wed, Jun 30, 2021 at 05:32:15PM +0530, Tejas Upadhyay wrote:
> Having different alignment requirement by different drivers,
> 256B aligned should work for all drm drivers.
What.
Like yes vgem abuses dumb_create, but it's not a kms driver. Pitch is
meaningless, and that's why we align it minima
On Wed, 30 Jun 2021 04:28:39 -0700
Joe Perches wrote:
> On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> > The __assign_str macro has an unusual ending semicolon but the vast
> > majority of uses of the macro already have semicolon termination.
>
> ping?
>
I wasn't sure I was the one
Hi Peng,
On Tue, Jun 29, 2021 at 12:40 PM Peng Fan (OSS) wrote:
>
> Hi Jagan,
>
> > Subject: [RFC PATCH 0/9] arm64: imx8mm: Add MIPI DSI support
> >
> > This series support MIPI DSI on i.MX8MM.
> >
> > It worked directly with existing mxsfb driver but the SEC DSIM timings has
> > to
> > be valid
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.
Then we should always also wait
> -Original Message-
> From: Daniel Vetter
> Sent: 30 June 2021 17:52
> To: Surendrakumar Upadhyay, TejaskumarX
>
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> ch...@chris-wilson.co.uk
> Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
>
>
Our dma-buf code is currently completely broken unless the importer is
dynamic in which case the sg_list caching saves the day. In particular,
the case where another instance of our driver tries to import a dma-buf
exported by our driver ends up in a recursive lock.
Since the recent TTM migration
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.
v3:
- Migrate also in the pin() callback.
Signed-off-by: Tho
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 same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a li
Reviewed-by: Alyssa Rosenzweig
On Wed, Jun 30, 2021 at 08:27:40AM +0200, Boris Brezillon wrote:
> Currently unused. We'll add it back if we need per-GPU definitions.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 2 +-
> dri
On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> 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 same reservation
> object
On Wed, Jun 30, 2021 at 12:46:27PM +, Surendrakumar Upadhyay, TejaskumarX
wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: 30 June 2021 17:52
> > To: Surendrakumar Upadhyay, TejaskumarX
> >
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
>-Original Message-
>From: Daniel Vetter
>Sent: Wednesday, June 30, 2021 10:02 AM
>To: Thomas Hellström ; Christian König
>
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Auld,
>Matthew ; maarten.lankho...@linux.intel.com;
>dan...@ffwll.ch; Ruhl, Michael J
>Subject
Move the bochs driver to tiny/ and simplify the clean-up code. Also
update GEM VRAM helpers accordingly.
Thomas Zimmermann (3):
drm/bochs: Move to tiny/
drm/bochs: Use managed initialization for GEM VRAM helpers
drm/vram-helper: Unexport drm_vram_helper_{alloc,release}_mm()
MAINTAINERS
The bochs driver is only ~600 lines of code. Putting it into tiny/
cleans up the DRM directory slightly. Some style problems were fixed
and unneeded include statements were removed. No functional changes.
Signed-off-by: Thomas Zimmermann
---
MAINTAINERS | 2 +-
drivers/gp
Convert to managed GEM VRAM initialization and switch bochs to
full autocleanup.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/bochs.c | 43 +---
1 file changed, 5 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/
All GEM-VRAM-based drivers use auto-cleanup via drmm_vram_helper_init().
Unexport the manual APIs and make them internal implementation.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 +++--
include/drm/drm_gem_vram_helper.h | 4
2 files changed, 3 in
On Wed, Jun 30, 2021 at 2:36 PM Christian König
wrote:
>
> Daniel pointed me towards this function and there are multiple obvious
> problems
> in the implementation.
>
> First of all the retry loop is not working as intended. In general the retry
> makes only sense if you grab the reference first
On Wed, Jun 30, 2021 at 04:06:57PM +0200, Thomas Zimmermann wrote:
> The bochs driver is only ~600 lines of code. Putting it into tiny/
> cleans up the DRM directory slightly. Some style problems were fixed
> and unneeded include statements were removed. No functional changes.
>
> Signed-off-by: T
On 30/06/2021 07:27, 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.
>
> v5:
> * Add a panfrost_exception_is_fault() helper and the
> DRM_PANFROST_EXCEPTION_MAX_NON_FAULT value
Hi
Am 30.06.21 um 12:49 schrieb Daniel Vetter:
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
v
On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
wrote:
>
> In order to make the code a bit more readable and to facilitate
> async memcpy moves, reorganize the move code a little. Determine
> at an early stage whether to copy or to clear.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/dr
Am 30.06.21 um 16:07 schrieb Daniel Vetter:
On Wed, Jun 30, 2021 at 2:36 PM Christian König
wrote:
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sens
On Thu, 24 Jun 2021 at 20:31, 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 h
Dear all,
The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.
Note that the first
Reset dsi0 HW to default when power on. This prevents to have different
settingbetween the bootloader and the kernel.
As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with
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 in
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 &dev->mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master which increments the
reference count of drm_file->master while holding a lock on
drm_device.master_mutex.
In preparation for this, the call to _drm_lease_held should be moved
out fr
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 i
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 dr
On 30/06/2021 07:27, 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.
>
> v5:
> * Fix a comment in panfrost_job_init()
>
> v3:
>
On 30/06/2021 07:27, Boris Brezillon wrote:
> Experience has shown that 1ms is sometimes not enough, even when the GPU
> is running at its maximum frequency, not to mention that an MMU operation
> might take longer if the GPU is running at a lower frequency, which is
> likely to be the case if devf
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.
I have now corrected the DSC behavior, but still no wait to test it.
Exact dithering behavior remains a mistery so in case dithering is active it's
not 100% clear what "active bpc" means, or where
This commit implements the "active bpc" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 27 insertions(+), 1 deletion(-)
diff -
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports d
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monito
This commit implements the "active bpc" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel color back to userspace.
While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
b
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 deletion
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2 deletions(-
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/g
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
2 files changed, 15 insertions(+), 3 deletions(-
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
diff --git a/d
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.
Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detect
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i91
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr4
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor a
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
3 f
On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> wrote:
> >
> > In order to make the code a bit more readable and to facilitate
> > async memcpy moves, reorganize the move code a little. Determine
> > at an early stage whether to copy or to
Hi Doug,
thanks for your review! I fixed most things except this:
On Fri, Jun 25, 2021 at 6:42 PM Doug Anderson wrote:
> > +static int ws2401_disable(struct drm_panel *panel)
> > +{
> > + struct ws2401 *ws = to_ws2401(panel);
> > +
> > + ws2401_command(ws, MIPI_DCS_SET_DISPLAY_OFF);
On Mon, Jun 28, 2021 at 11:30 AM Noralf Trønnes wrote:
> > + dev_info(ws->dev, "MTP ID: %02x %02x %02x\n", id1, id2, id3);
> > +}
>
> Why do you read these id's on every power on, it doesn't look like you
> use them?
>
> If they're just informational, they should be available through debugfs,
Hi Will and Claire,
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor wrote:
> > >
> > > On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote:
> > > > Propagate
On Wed, Jun 30, 2021 at 4:22 PM Christian König
wrote:
>
> Am 30.06.21 um 16:07 schrieb Daniel Vetter:
> > On Wed, Jun 30, 2021 at 2:36 PM Christian König
> > wrote:
> >> Daniel pointed me towards this function and there are multiple obvious
> >> problems
> >> in the implementation.
> >>
> >> Fi
Hi Ezequiel,
Am 29.06.21 um 14:28 schrieb Ezequiel Garcia:
Hi Alex,
On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
Hi Ezequiel,
Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
(Adding Nicolas)
Hi Alex,
On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
Hi Ezequiel,
Am 24.06.21 um 20:26
Hello folks,
I'm currently trying to understand how the virtio-gpu driver actually
works and got a few noob questions:
1. virtio_gpu_pci_quirk():
* what is the explicit framebuffer removal about ?
Do virtio-gpu devices support several framebuffer types (but only
one at a time) ? How
On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
wrote:
>
> On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > wrote:
> > >
> > > In order to make the code a bit more readable and to facilitate
> > > async memcpy moves, reorganize the move
On Wed, Jun 30, 2021 at 6:54 PM Matthew Auld
wrote:
>
> On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
> wrote:
> >
> > On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > > wrote:
> > > >
> > > > In order to make the code a bit more re
On Wed, Jun 30, 2021 at 4:18 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.06.21 um 12:49 schrieb Daniel Vetter:
> > On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> >> The code in xcs_resume() probably didn't work as intended. It uses
> >> struct drm_device.irq, which is alloca
On Wed, Jun 30, 2021 at 4:01 PM Daniel Vetter wrote:
> On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> > 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
On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:
>
>
> On 24/06/2021 10:05, Matthew Brost wrote:
> > From: Daniele Ceraolo Spurio
> >
> > Unblock GuC submission on Gen11+ platforms.
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-
This adds device tree bindings for the Samsung Mobile Displays
LMS380KF01 RGB DPI display panel.
Cc: devicet...@vger.kernel.org
Cc: phone-de...@vger.kernel.org
Cc: Douglas Anderson
Cc: Noralf Trønnes
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Expect SPI bindings to be pulled in for th
This adds a driver for panels based on the WideChips WS2401 display
controller. This display controller is used in the Samsung LMS380KF01
display found in the Samsung GT-I8160 (Codina) mobile phone and
possibly others.
As is common with Samsung displays manufacturer commands are necessary
to confi
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/int
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #28 from Leandro Jacques (ls...@yahoo.com) ---
(In reply to Leandro Jacques from comment #25)
Until now, no problems. So the problem is with newer firmware versions, working
without any issues since 2021-06-21 19:26:28 UTC with versio
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #30 from Leandro Jacques (ls...@yahoo.com) ---
(In reply to Leandro Jacques from comment #29)
Until now, no problems. So the problem is with newer firmware versions, working
without any issues since 2021-06-22 17:16:25 UTC with versio
1 - 100 of 122 matches
Mail list logo
