Hi Dave, Daniel,
Fixes for 5.14.
The following changes since commit b322a50d17ede5cff6622040f345228afecdcc45:
Merge tag 'amd-drm-next-5.14-2021-06-22-1' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-06-24 07:57:41
+1000)
are available in the Git repository at:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
between commit:
da68547d3692 ("drm/amdgpu: use vma_lookup() in
amdgpu_ttm_tt_get_user_pages()")
from Linus' tree and commit:
04d8d73dbcbe ("drm/amdgpu: add common HMM get pages
On Thu, Jul 01, 2021 at 01:23:36AM +0200, Michal Wajdeczko wrote:
>
>
> On 28.06.2021 01:14, Matthew Brost wrote:
> > Implement a stall timer which fails H2G CTBs once a period of time
> > with no forward progress is reached to prevent deadlock.
> >
> > v2:
> > (Michal)
> > - Improve error
On Thu, Jul 01, 2021 at 12:52:58AM +0200, Michal Wajdeczko wrote:
>
>
> On 28.06.2021 01:14, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> > will send CTBs in the critical path and does not need to wait for these
> > CTBs to complete before
None of supported devies uses "gdsc" regulator for DSI. GDSC support is
now implemented as a power domain. Drop old code and config handling
gdsc regulator requesting and enabling.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 12
On 28.06.2021 01:14, Matthew Brost wrote:
> Implement a stall timer which fails H2G CTBs once a period of time
> with no forward progress is reached to prevent deadlock.
>
> v2:
> (Michal)
> - Improve error message in ct_deadlock()
> - Set broken when ct_deadlock() returns true
> -
Hi Thomas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20210630]
[cannot apply to linus/master v5.13 v5.13-rc7 v5.13-rc6 v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
drivers/gpu/drm/tiny/bochs.c:542:36: warning: symbol 'bochs_mode_funcs' was not
declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
bochs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c
On 28.06.2021 01:14, Matthew Brost wrote:
> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> will send CTBs in the critical path and does not need to wait for these
> CTBs to complete before moving on, hence the need for this new function.
>
> The non-blocking CTB now
On 6/29/21 10:02 AM, Lucas Stach wrote:
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
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
On 6/21/21 2:13 PM, Laurent Pinchart wrote:
Hi Marek,
Thank you for the patch.
On Mon, Jun 21, 2021 at 12:47:01AM +0200, Marek Vasut wrote:
There is some sort of corner case behavior of the controller,
which could rarely be triggered at least on i.MX6SX connected
to 800x480 DPI panel and
On Wed, Jun 30, 2021 at 2:10 AM Christian König
wrote:
> Am 30.06.21 um 03:34 schrieb John Stultz:
> > +static unsigned long page_pool_size; /* max size of the pool */
> > +
> > +MODULE_PARM_DESC(page_pool_size, "Number of pages in the drm page pool");
> > +module_param(page_pool_size, ulong,
> On Jun 30, 2021, at 16:32, Randy Dunlap wrote:
>
> Add a header file for ttm_range_manager function prototypes to
> eliminate build errors:
>
> ../drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function ‘vmw_vram_manager_init’:
> ../drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:678:8: error: implicit
nlap
Cc: "VMware Graphics"
Cc: Roland Scheidegger
Cc: Zack Rusin
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie
Cc: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 +
1 file changed, 1 insertion(+)
--- linux-next-20210630.orig/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++
Den 30.06.2021 21.46, skrev Noralf Trønnes:
>
>
> Den 30.06.2021 21.13, skrev Linus Walleij:
>> This creates a macro wrapping mipi_dbi_command() such that we get
>> some explicit error reporting if something goes wrong.
>>
>> Cc: Noralf Trønnes
>> Suggested-by: Douglas Anderson
>>
Den 30.06.2021 21.13, skrev Linus Walleij:
> This creates a macro wrapping mipi_dbi_command() such that we get
> some explicit error reporting if something goes wrong.
>
> Cc: Noralf Trønnes
> Suggested-by: Douglas Anderson
> Signed-off-by: Linus Walleij
> ---
>
Den 30.06.2021 20.28, skrev Linus Walleij:
> 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
This creates a macro wrapping mipi_dbi_command() such that we get
some explicit error reporting if something goes wrong.
Cc: Noralf Trønnes
Suggested-by: Douglas Anderson
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-samsung-db7430.c | 66 +++-
1 file changed,
On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
> 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
From: Maitreyee Rao
Add trace points across the MSM DP driver to help debug
interop issues.
Changes in v2:
- Got rid of redundant log messages.
- Added %#x instead of 0x%x wherever required.
- Got rid of __func__ calls in debug messages.
- Added newline wherever missing.
Signed-off-by:
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
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
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
---
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
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
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
> >
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
> >
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
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
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
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) ?
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
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.
> >>
> >>
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:
> > > >
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
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,
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
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
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
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)
-
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
---
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
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
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 +
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
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
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 "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
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
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
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
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
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
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
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
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
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:
>
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 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
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
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
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
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
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
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
> ---
>
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.
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
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:
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
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
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
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 +-
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
>-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
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;
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
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 +-
>
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
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:
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
> -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
>
>
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
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
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
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
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
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
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
> -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
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?
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
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
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
>
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
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)
>
>
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
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:
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
1 - 100 of 138 matches
Mail list logo
