By default dma_buf_export() sets the exporter name to be
KBUILD_MODNAME. Unfortunately this may not be identical to the
string used as the heap name (ie: "system" vs "system_heap").
This can cause some minor confusion with tooling, and there is
the future potential where multiple heap types may
It can be useful to access the name for the heap,
so provide an accessor to do so.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc:
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #75 from michael (lkb...@deegan.id.au) ---
An update. Now on 5.10.0-2-amd64.
Fresh boot, with amdgpu.dc=1, everything is mostly fine. pwm1_enable=2. Except
that after resuming from suspend, pwm1_enable=1 and pwm1=255, resulting in
On Fri, Feb 5, 2021 at 12:47 PM John Stultz wrote:
>
> On Fri, Feb 5, 2021 at 12:47 AM Christian König
> wrote:
> > Am 05.02.21 um 09:06 schrieb John Stultz:
> > > diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
> > > new file mode 100644
> > > index
On Sat, Feb 6, 2021 at 1:55 AM Rob Herring wrote:
>
> On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote:
> > Define a compatible string for the Mali Bifrost GPU found in
> > Mediatek's MT8183 SoCs.
> >
> > Signed-off-by: Nicolas Boichat
> > ---
> >
> > Changes in v11:
> > - binding:
On Fri, Feb 5, 2021 at 6:45 PM Lyude Paul wrote:
>
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
> 1 file
On 2021-02-02 19:08, Yang Li wrote:
Eliminate the following coccicheck warning:
./drivers/gpu/drm/msm/dp/dp_ctrl.c:1161:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
---
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
Signed-off-by: Lyude Paul
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 file
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
v3 series-wide changes:
* Split
Quoting Kuogee Hsieh (2021-02-05 12:44:38)
> DP_SW_RESET is the global SW reset that is used to initialize DP
> controller. If DP_SW_RESET executed during connection setup,
> two HPD related side effects may occurred,
> 1) pending HPD interrupts cleared unexpected
> 2) re start debounce logic
On 2/5/21 5:10 PM, Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 5:22 PM Andrey Grodzovsky
wrote:
Daniel, ping. Also, please refer to the other thread with Bjorn from pci-dev
on the same topic I added you to.
Summarizing my take over there for here plus maybe some more
clarification.
This is the third version of the patch series. Change log:
v3:
* Limit the use of find_path() to checking headers installed by the
kernel-headers package only
* Add status summary when DRM headers are not found
* Rework how dmabuf_alloc.c or dmabuf_alloc_stub.c is selected
v2:
Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
that are installed by either the kernel-header or the libdrm package.
The installation is optional and the location is not unique.
Check the presence and location of the headers and, if the headers
are missing, replace the dmabuf
Rename the parameter 'unit' to 'gpu'. Expand GTT to the full name in the
comments.
Signed-off-by: Jianxin Xiong
Reviewed-by: John Hubbard
---
pyverbs/dmabuf.pyx | 12
pyverbs/dmabuf_alloc.c | 12
pyverbs/dmabuf_alloc.h | 2 +-
pyverbs/mr.pyx | 6 ++--
Commit 6b0a3238289f ("verbs: Support dma-buf based memory region") caused
a build failure when building for 32b systems with gcc:
$ mkdir build && cd build && CFLAGS="-m32" cmake -GNinja .. \
-DIOCTL_MODE=both -DNO_PYVERBS=1 -DENABLE_WERROR=1 && ninja
...
../libibverbs/cmd_mr.c: In function
On Thu, Feb 4, 2021 at 6:55 PM James Park wrote:
>
> Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
>
> Copy type definitions from drm.h to drm_fourcc.h, and wrap with
> DRM_BASIC_TYPED_DEFINED to avoid redundant inclusion.
>
> This will allow code to avoid unnecessary
On Fri, Feb 5, 2021 at 5:22 PM Andrey Grodzovsky
wrote:
>
> Daniel, ping. Also, please refer to the other thread with Bjorn from pci-dev
> on the same topic I added you to.
Summarizing my take over there for here plus maybe some more
clarification. There's two problems:
- You must guarantee
On Thu, Jan 28, 2021 at 10:23:41AM +0800, Nick Fan wrote:
> Add devicetree schema for Arm Mali Valhall GPU
>
> Define a compatible string for the Mali Valhall GPU
> for Mediatek's SoC platform.
>
> Signed-off-by: Nick Fan
> ---
> .../bindings/gpu/arm,mali-valhall.yaml| 217
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend upon it. In particular, Mesa uses SYS_kcmp for
os_same_file_description() in order to identify when two fd (e.g. device
or dmabuf) point to the same struct file. Since they depend on it for
core functionality,
On 05/02/2021 22.06, Chris Wilson wrote:
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct
DP_SW_RESET is the global SW reset that is used to initialize DP
controller. If DP_SW_RESET executed during connection setup,
two HPD related side effects may occurred,
1) pending HPD interrupts cleared unexpected
2) re start debounce logic which trigger another interrupt
This patch only issue
On Fri, Feb 5, 2021 at 10:28 PM Chris Wilson wrote:
>
> Quoting Kees Cook (2021-02-05 21:20:33)
> > On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote:
> > > The subject should of course be changed, as it is no longer being
> > > enabled by default.
> >
> > "default n" is redundant.
>
>
Quoting Kees Cook (2021-02-05 21:20:33)
> On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote:
> > The subject should of course be changed, as it is no longer being
> > enabled by default.
>
> "default n" is redundant.
I thought being explicit would be preferred. There are a few other
On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote:
> The subject should of course be changed, as it is no longer being
> enabled by default.
"default n" is redundant. I thought Daniel said CONFIG_DRM needed to
"select" it too, though? Otherwise, yeah, this looks good. Was the
export
On Fri, Feb 05, 2021 at 06:24:08PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > > > On Thu, Feb 04, 2021 at
The subject should of course be changed, as it is no longer being
enabled by default.
Something like
kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
Quoting Chris Wilson (2021-02-05 21:06:10)
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend upon it. In particular, Mesa uses SYS_kcmp for
os_same_file_description() in order to identify when two fd (e.g. device
or dmabuf) point to the same struct file. Since they depend on it for
core functionality,
On Fri, Feb 5, 2021 at 2:36 AM Christian König wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > Input would be greatly appreciated. Testing as well, as I don't
> > have any development hardware that utilizes the ttm pool.
>
> We can easily do the testing and the general idea sounds solid to
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
>
> On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order
On Fri, Feb 5, 2021 at 12:47 AM Christian König
wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
> > new file mode 100644
> > index ..2139f86e6ca7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/page_pool.c
> >
On Fri, Feb 5, 2021 at 2:56 AM Christian König wrote:
>
> Am 05.02.21 um 03:23 schrieb Kalesh Singh:
> > If a FD refers to a DMA buffer add the DMA buffer inode number to
> > /proc//fdinfo/ and /proc//task//fdindo/.
> >
> > The dmabuf inode number allows userspace to uniquely identify the buffer
On 2/5/21 7:53 AM, Daniel Vetter wrote:
On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
And again, for slightly older hardware, without pinning to VRAM there is
no way to use this solution here for peer-to-peer.
On Fri, Feb 05, 2021 at 10:06:48PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 05, 2021 at 12:07:41PM -0800, Navare, Manasi wrote:
> > On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote:
> > > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote:
> > > > DP-HDMI2.1 PCON has DSC
On Fri, Feb 05, 2021 at 12:07:41PM -0800, Navare, Manasi wrote:
> On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote:
> > > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E.
> > > Do not read the
On Fri, Feb 05, 2021 at 09:58:07PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote:
> > DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E.
> > Do not read the registers if DPCD rev < 1.4.
> >
> > Fixes:
On Thu, Feb 04, 2021 at 12:18:42PM +0530, Ankit Nautiyal wrote:
> Remove code for resetting frl related members from intel_disable_dp, as
> this is not applicable for older platforms.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 --
> 1 file changed, 2
On Thu, Feb 04, 2021 at 12:18:41PM +0530, Ankit Nautiyal wrote:
> Currently the FRL training mode (Concurrent, Sequential) and
> training type (Normal, Extended) are not defined properly and
> are passed as bool values in drm_helpers for pcon
> configuration for FRL training.
>
> This patch:
>
On Thu, Feb 04, 2021 at 12:18:40PM +0530, Ankit Nautiyal wrote:
> DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E.
> Do not read the registers if DPCD rev < 1.4.
>
> Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868
> Signed-off-by: Ankit Nautiyal
> ---
>
On Fri, Feb 5, 2021 at 12:28 AM Christian König
wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > This refactors ttm_pool_free_page(), and by adding extra entries
> > to ttm_pool_page_dat, we then use it for all allocations, which
> > allows us to simplify the arguments needed to be passed
2ab38c17aac10bf55ab3efde4c4db3893d8691d2
config: i386-randconfig-s002-20210205 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-215-g0fb77bb6-dirty
#
https://github.com/0day-ci/linux/commit
2ab38c17aac10bf55ab3efde4c4db3893d8691d2
config: powerpc-randconfig-r023-20210205 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp
https://bugzilla.kernel.org/show_bug.cgi?id=210849
--- Comment #14 from JerryD (jvdeli...@charter.net) ---
(In reply to Alex Deucher from comment #13)
> most likely kernel.
>
> https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html
OK, I have done the kernel builds before no
Dne petek, 05. februar 2021 ob 17:28:23 CET je Chen-Yu Tsai napisal(a):
> On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec
wrote:
> >
> > Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Feb
https://bugzilla.kernel.org/show_bug.cgi?id=210849
--- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) ---
most likely kernel.
https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to
On 2/5/21 12:47 AM, Bhaskar Chowdhury wrote:
>
>
> s/confguration/configuration/
> s/Regsiters/Registers/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
The pull request you sent on Fri, 5 Feb 2021 11:43:49 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-05-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8e91dd934be6131143df5db05fb06635581addf9
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Jan 21, 2021 at 04:29:58PM +0100, Daniel Vetter wrote:
> Again ends just after drm_atomic_helper_commit_hw_done(), but with the
> twist that we need to make sure we're only annotate the custom
> version. And not the other clause which just calls
> drm_atomic_helper_commit_tail_rpm(), which
On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote:
> Define a compatible string for the Mali Bifrost GPU found in
> Mediatek's MT8183 SoCs.
>
> Signed-off-by: Nicolas Boichat
> ---
>
> Changes in v11:
> - binding: power-domain-names not power-domainS-names
>
> Changes in v10:
> - Fix
https://bugzilla.kernel.org/show_bug.cgi?id=210849
--- Comment #12 from JerryD (jvdeli...@charter.net) ---
I have done some bisection with the kernel by uninstalling packages and rolling
back. I tried this with my best guess of which packages to roll back using
package manager (dnf here). In the
On Tue, Jan 26, 2021 at 10:32:00PM +0100, Linus Walleij wrote:
> The KTD253 backlight might already be on when the driver
> is probed: then we don't really know what the current
> ratio is and all light intensity settings will be off
> relative to what it was at boot.
>
> To fix this, bring up
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, February 05, 2021 5:54 AM
> To: Jason Gunthorpe
> Cc: Xiong, Jianxin ; Yishai Hadas
> ; Leon Romanovsky ; linux-rdma r...@vger.kernel.org>; John Hubbard ; Edward Srouji
> ; Emil Velikov
> ; Gal Pressman ; dri-devel
> ; Doug
Am Freitag, dem 05.02.2021 um 16:37 + schrieb Chris Wilson:
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point
On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
> >
> > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > is no issue if
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend upon it. In particular, Mesa uses SYS_kcmp for
os_same_file_description() in order to identify when two fd (e.g. device
or dmabuf) point to the same struct file. Since they depend on it for
core functionality,
On Wed, Feb 3, 2021 at 7:42 AM Takashi Iwai wrote:
>
> The current code tries to read the brightness value via
> dc_link_get_backlight_level() no matter whether it's controlled via
> aux or not, and this results in a bogus value returned.
> Fix it to read the current value via
>
On Wed, Feb 3, 2021 at 7:42 AM Takashi Iwai wrote:
>
> There seem devices that don't work with the aux channel backlight
> control. For allowing such users to test with the other backlight
> control method, provide a new module option, aux_backlight, to specify
> enabling or disabling the aux
On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec wrote:
>
> Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> > > >
> > > > Channel 1 has polarity
On Fri, Feb 05, 2021 at 04:46:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > >
Daniel, ping. Also, please refer to the other thread with Bjorn from pci-dev
on the same topic I added you to.
Andrey
On 1/29/21 2:25 PM, Christian König wrote:
Am 29.01.21 um 18:35 schrieb Andrey Grodzovsky:
On 1/29/21 10:16 AM, Christian König wrote:
Am 28.01.21 um 18:23 schrieb Andrey
Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
wrote:
> > >
> > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > sets them.
Am Freitag, dem 05.02.2021 um 16:59 +0100 schrieb Daniel Vetter:
> On Fri, Feb 05, 2021 at 04:58:32PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote:
> > > gallium (iris) depends on os_same_file_description() to disambiguate
> > > screens and so avoid
On Fri, Feb 05, 2021 at 12:00:03PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 04:53:04PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> > > On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> > >
> > > > > And again,
On Tue, Feb 02, 2021 at 11:35:16PM -0800, Vivek Kasireddy wrote:
> This driver "transfers" a dmabuf created on the Guest to the Host.
> A common use-case for such a transfer includes sharing the scanout
> buffer created by a display server or a compositor running in the
> Guest with Qemu UI --
On Fri, Feb 05, 2021 at 04:53:04PM +0100, Daniel Vetter wrote:
> On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> >
> > > > And again, for slightly older hardware, without pinning to VRAM there is
> > > > no way
On Fri, Feb 05, 2021 at 04:58:32PM +0100, Daniel Vetter wrote:
> On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote:
> > gallium (iris) depends on os_same_file_description() to disambiguate
> > screens and so avoid importing the same screen fd twice as two distinct
> > entities (that
On Fri, Feb 05, 2021 at 01:03:07PM +, Chris Wilson wrote:
> gallium (iris) depends on os_same_file_description() to disambiguate
> screens and so avoid importing the same screen fd twice as two distinct
> entities (that share all the kernel resources, so actions on screen
> affect the other
On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
>
> > > And again, for slightly older hardware, without pinning to VRAM there is
> > > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > >
On Thu, Feb 04, 2021 at 05:55:28PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2021 at 04:32:16PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > drm_vblank_restore() exists because certain power saving states
On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> > And again, for slightly older hardware, without pinning to VRAM there is
> > no way to use this solution here for peer-to-peer. So I'm glad to see that
> > so far you're not ruling out the pinning option.
>
> Since HMM and
https://bugzilla.kernel.org/show_bug.cgi?id=210849
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Thu, Feb 04, 2021 at 11:00:32AM -0800, John Hubbard wrote:
> On 2/4/21 10:44 AM, Alex Deucher wrote:
> ...
> > > > The argument is that vram is a scarce resource, but I don't know if
> > > > that is really the case these days. At this point, we often have as
> > > > much vram as system ram if
On Feb 5, 2021, at 2:43 AM, Gerd Hoffmann wrote:
>
> On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote:
>> if qxl_device_init() fail, drm device will not be registered,
>> in this case, do not run qxl_drm_release()
>
> How do you trigger this?
>
This can be triggered by changing the
[AMD Official Use Only - Internal Distribution Only]
I think the virt team probably wants it in amd-staging-drm-next so they can
start testing it. 5.12 is getting pretty tight. I'm not sure if there will be
another drm-misc PR or not for 5.12. Rebasing amd-staging-drm-next is turning
into a
Just like regular plane-state helpers, drivers can use these new
callbacks to create and destroy private plane state.
v2:
* make duplicate_state interface compatible with
struct drm_plane_funcs
Signed-off-by: Thomas Zimmermann
Tested-by: Gerd Hoffmann
Acked-by: Gerd Hoffmann
Several SHMEM-based drivers use the BO as shadow buffer for the real
framebuffer memory. Damage handling requires a vmap of the BO memory.
But vmap/vunmap can acquire the dma-buf reservation lock, which is not
allowed in commit tails.
This patchset introduces a set of helpers that implement
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Several drivers use GEM buffer objects as shadow buffers for the actual
framebuffer memory. Right now, drivers do these vmap operations in their
commit tail, which is actually not allowed by the locking rules for
the dma-buf reservation lock. The involved BO has to be vmapped in the
plane's
The symbols will be required by the upcoming helpers for shadow-buffered
planes.
Signed-off-by: Thomas Zimmermann
Reported-by: kernel test robot
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index
Vmap operations may acquire the dmabuf reservation lock, which is not
allowed within atomic commit-tail functions. Therefore move vmap and
vunmap from the damage handler into prepare_fb and cleanup_fb callbacks.
The mapping is provided as GEM shadow-buffered plane. The functions in
the commit
Hi Sebastian,
I did some tests myself today as well and can confirm your
hdmi related finding - at least when plugged in on boot.
I tried some combinations of camera vs. hdmi and it seems
really only when hdmi is plugged in on boot
(1)
- boot
- camera
--> works
(2)
- boot
- camera
- hdmi
The alternative is to wait till drm-misc-next is merged into drm-next,
then rebase amd-staging-drm-next on top of that (or directly
drm-misc-next) and push then.
Would give us at least a clean history. Question is rather if we want it
in 5.12?
Christian.
Am 05.02.21 um 15:50 schrieb
[AMD Official Use Only - Internal Distribution Only]
Good question. I think push it to drm-misc-next for upstream. We can carry it
internally in amd-staging-drm-next for internal testing and I can coordinate
with drm-next. I think the amdgpu changes are pretty straightforward, so
shouldn't
Merged.
Am 04.02.21 um 20:11 schrieb Colin King:
From: Colin Ian King
Don't populate the const array m_div_val on the stack but instead make
it static. Makes the object code smaller by 29 bytes:
Before:
text data bss dechex filename
34736 4552 0 39288
Am 05.02.21 um 14:22 schrieb Thomas Zimmermann:
All errors (new ones prefixed by >>, old ones prefixed by <<):
ERROR: modpost: "drm_gem_vunmap" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
ERROR: modpost: "drm_gem_vmap" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
These are in
This series attempts to enable V3D on BCM2711, the SoC available on the
Raspberry Pi 4 family of boards.
Due to the lack of documentation some things are taken as it from
testing/downstream implementation[1], which I'm hilighting here:
- It's not clear that the following is 100% true, maybe
Add compatible string and Kconfig options for bcm2711.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
Runtime PM doesn't seem to work correctly on this driver. On top of
that, commit 8b6864e3e138 (drm/v3d/v3d_drv: Remove unused static
variable 'v3d_v3d_pm_ops') hints that it most likely never did properly
as the driver's PM ops were not hooked-up.
So, in order to support regular operation with
On Fri, Feb 05, 2021 at 02:08:47PM +0100, Uwe Kleine-König wrote:
> This was non-trivial to get right because commits
> c23bc382ef0e ("coresight: etm4x: Refactor probing routine") and
> 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
> changed the code flow considerably.
1 - 100 of 176 matches
Mail list logo
