Hi, Hsin-yi:
On Mon, 2021-07-12 at 17:46 +0800, Hsin-Yi Wang wrote:
> atomic_get_output_bus_fmts() is only called when the bridge is the last
> element in the bridge chain.
>
> If mtk-dpi is not the last bridge, the format of output_bus_cfg is
> MEDIA_BUS_FMT_FIXED, and mtk_dpi_dual_edge() will
On Mon, Jul 12, 2021 at 9:03 AM Yongqiang Niu
wrote:
>
> mt8183 aal has no gamma function
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 166
>
>
On Wed, Jul 14, 2021 at 11:32:35AM +0300, Laurent Pinchart wrote:
> Hi Xin,
>
> On Wed, Jul 07, 2021 at 03:30:51PM +0800, Xin Ji wrote:
> > On Thu, Jun 24, 2021 at 01:57:22PM +0200, Robert Foss wrote:
> > > Hey Xin,
> > >
> > > I would like to merge this series now, but this patch needs a review
On Tue, Jul 13, 2021 at 04:10:10PM -0600, Rob Herring wrote:
> On Wed, Jul 07, 2021 at 03:30:51PM +0800, Xin Ji wrote:
> > On Thu, Jun 24, 2021 at 01:57:22PM +0200, Robert Foss wrote:
> > > Hey Xin,
> > >
> > > I would like to merge this series now, but this patch needs a review
> > > first.
Hi, Frank:
On Mon, 2021-07-12 at 10:07 +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich
>
> bridge->driver_private is not set (NULL) so use bridge_to_dpi(bridge)
> like it's done in bridge_atomic_get_output_bus_fmts
Reviewed-by: CK Hu
>
> Fixes: ec8747c52434 ("drm/mediatek: dpi: Add
Note that discrete cards can support PXP as well, but we haven't tested
on those yet so keeping it disabled for now.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Anshuman Gupta
Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PXP session is enabled.
2. Buffer object is protected.
v2:
- Used gen fb obj user_flags instead gem_object_metadata.
From: "Huang, Sean Z"
Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume
v2: emit in
From: Anshuman Gupta
When protected sufaces has flipped and pxp session is disabled,
display black pixels by using plane color CTM correction.
v2:
- Display black pixels in async flip too.
v3:
- Removed the black pixels logic for async flip. [Ville]
- Used plane state to force black pixels.
Now that we can handle destruction and re-creation of the arb session,
we can postpone the start of the session to the first submission that
requires it, to avoid keeping it running with no user.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
From: "Huang, Sean Z"
The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done with the termination it will generate another interrupt, at
which point it is safe to re-create the session.
Since the
From: "Huang, Sean Z"
During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
session state might still be marked as alive after resume. Therefore,
we should consider the session as dead on suspend and invalidate all the
Ahead of the PXP implementation, define the relevant define flag and
kconfig option.
v2: flip kconfig default to N. Some machines have IFWIs that do not
support PXP, so we need it to be an opt-in until we add support to query
the caps from the mei device.
Signed-off-by: Daniele Ceraolo Spurio
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.
Contexts can only be marked as using protected content at creation time
(i.e. the parameter is
From: "Huang, Sean Z"
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.
v2: fix locking, don't pollute dev_priv (Chris)
v3: wait for mei PXP component to be bound.
v4: drop the wait, as the
The setting is required by hardware to allow us doing further protection
operation such as sending commands to GPU or TEE. The register needs to
be re-programmed on resume, so for simplicitly we bundle the programming
with the component binding, which is automatically called on resume.
Further HW
From: "Huang, Sean Z"
Create the arbitrary session, with the fixed session id 0xf, after
system boot, for the case that application allocates the protected
buffer without establishing any protection session. Because the
hardware requires at least one alive session for protected buffer
creation.
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.
v2: use perma-pinned context (Chris)
v3: rename pinned_context functions (Chris)
PXP (Protected Xe Path) is an i915 component, available on
GEN12+, that helps to establish the hardware protected session
and manage the status of the alive software session, as well
as its life cycle.
The main changes in v5 are:
- Rebased to new proto_ctx implementation.
- Squashed all uapi
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/misc/mei/Kconfig | 2 +
This will be used for communication between the i915 driver and the mei
one. Defining it in a stand-alone patch to avoid circualr dependedencies
between the patches modifying the 2 drivers.
Split out from an original patch from Huang, Sean Z
v2: rename the component struct (Rodrigo)
Implement virtgpu specific map_dma_buf callback to support mapping
exported vram object dma-bufs. The dma-buf callback is used directly, as
vram objects don't have backing pages and thus can't implement the
drm_gem_object_funcs.get_sg_table callback.
Signed-off-by: David Stevens
---
Hi Linus,
Regular rc2 fixes though a bit more than usual at rc2 stage, people
must have been testing early or else some fixes from last week got a
bit laggy. There is one larger change in the amd fixes to amalgamate
some power management code on the newer chips with the code from the
older chips,
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on 4d00e2309398147acdbfefbe1deb4b0e78868466]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Provide-framebuffer-vmap-helpers/20210716-020508
base: 4d00e2309398147acdbfefbe1deb4b0e78868466
I tested this patch set on the 9x60ek board and unfortunately it causes
errors. The vbltest returns -1 and I also see the display get out of
sync while testing with a gui application.
Regards,
Dan
Although 'err' has been initialized to -ENOMEM, but it will be reassigned
by the "err = create_vmas(...)" statement in the for loop. So that, the
value of 'err' may be zero when i915_gem_object_create_internal() or
mock_context() failed.
Fix to reassign 'err' before 'goto out'.
Fixes:
config: arm64-randconfig-r035-20210715 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
0e49c54a8cbd3e779e5526a5888c683c01cc3c50)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
Hi Marijn
Sorry for the late response.
On 2021-07-13 02:10, Marijn Suijten wrote:
On 6/29/21 9:04 PM, Abhinav Kumar wrote:
During board bringups its useful to have a DSI test pattern
generator to isolate a DPU vs a DSI issue and focus on the relevant
hardware block.
To facilitate this, add
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin()
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the object and pass
that into ttm_bo_init_reserved().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Whenever we had a user object (n_placements > 0), we were ignoring
obj->mm.region and always putting obj->placements[0] as the requested
region. For LMEM+SMEM objects, this was causing them to get shoved into
LMEM on every i915_ttm_get_pages() even when SMEM was requested by, say,
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, the only functional change here
should be that i915_gem_dumb_create now calls i915_gem_flush_free_objects
which it
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from
config: nios2-randconfig-s032-20210715 (attached as .config)
compiler: nios2-linux-gcc (GCC) 10.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
On Thu, 15 Jul 2021 19:11:49 -0300
Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> > On Wed, 14 Jul 2021 21:20:38 -0300
> > Jason Gunthorpe wrote:
> > > +/*
> > > + * We need to get memory_lock for each device, but devices can share
> > >
On 6/16/2021 03:25, Daniel Vetter wrote:
On Thu, Jun 10, 2021 at 10:46 PM wrote:
From: John Harrison
Various UMDs need to know the L3 bank count. So add a query API for it.
Please link to both the igt test submission for this (there's not even
a Test-with: on the cover letter)
Is there a
On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> On Wed, 14 Jul 2021 21:20:38 -0300
> Jason Gunthorpe wrote:
> > +/*
> > + * We need to get memory_lock for each device, but devices can share
> > mmap_lock,
> > + * therefore we need to zap and hold the vma_lock for each device,
Hi Dan,
On Thu, Jul 15, 2021 at 09:55:09PM +, dan.sned...@microchip.com wrote:
> I tested this patch set on the 9x60ek board and unfortunately it causes
> errors. The vbltest returns -1 and I also see the display get out of
> sync while testing with a gui application.
Thanks a lot for the
Reviewed-by: Lyude Paul
On Wed, 2021-07-14 at 10:15 -0700, Randy Dunlap wrote:
> Fix build errors and warnings when
> # CONFIG_DRM_NOUVEAU_BACKLIGHT is not set
>
> ../drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> ‘nv50_sor_atomic_disable’:
>
Hi Stephen,
Thanks for reviewing my code.
On 2021-07-08 18:27, Stephen Boyd wrote:
Quoting maitreye (2021-07-08 12:13:44)
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
https://bugzilla.kernel.org/show_bug.cgi?id=213751
Bug ID: 213751
Summary: KVM virt w/ qxl fails boot at latest 5.14.0-rc1+
Product: Drivers
Version: 2.5
Kernel Version: 5.14.0-rc1+
Hardware: x86-64
OS: Linux
On Wed, 14 Jul 2021 21:20:38 -0300
Jason Gunthorpe wrote:
> +/*
> + * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> + * therefore we need to zap and hold the vma_lock for each device, and only
> then
> + * get each memory_lock.
> + */
> +static int
On 2021-07-15 3:19 p.m., Mario Kleiner wrote:
> On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
>>
>> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
>>>
>>> Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
>>> 30bpp for DCE-11.0.") doesn't seems to have fixed
On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
>
> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
> >
> > Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
> > 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
> > DisplayPort for CIK GPUs. On
On Thu, Jul 15, 2021 at 1:21 PM Kenneth Graunke wrote:
>
> On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
> >
> > On 15/07/2021 12:07, Daniel Vetter wrote:
> > > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 15/07/2021 11:15, Matthew Auld wrote:
From: Thomas Zimmermann
commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
from struct drm_device.dev to get the PCI device structure.
v9:
* fix remaining pdev references
Signed-off-by: Thomas Zimmermann
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings, which causes mmap to fail
in ttm_bo_mmap_obj.
As a workaround, clear VM_MAYWRITE for PROT_NONE-COW mappings. This
should prevent the mapping from ever becoming writable and makes
From: Thomas Zimmermann
commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
from struct drm_device.dev to get the PCI device structure.
v9:
* fix remaining pdev references
Signed-off-by: Thomas Zimmermann
Quoting khs...@codeaurora.org (2021-07-09 10:16:52)
> On 2021-07-08 00:21, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-07-06 10:20:20)
> >> Main link symbol locked is achieved at end of link training 2. Some
> >> dongle main link symbol may become unlocked again if host did not end
> >>
Quoting khs...@codeaurora.org (2021-07-09 10:46:41)
> On 2021-07-08 00:33, Stephen Boyd wrote:
> >> +
> >> +static bool dp_ctrl_any_lane_cr_lose(struct dp_ctrl_private *ctrl,
> >> + u8 *cr_status)
> >> +{
> >> + int i;
> >> + u8 status;
> >> +
From: Thomas Zimmermann
commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream.
Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev()
from struct drm_device.dev to get the PCI device structure.
v9:
* fix remaining pdev references
Signed-off-by: Thomas Zimmermann
From: Ville Syrjälä
We have the modeset lock dance hand rolled in quite a few places.
Use drm_modeset_lock_ctx_retry() and drm_modeset_lock_all_ctx_retry()
to simplify our lives.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c |
From: Ville Syrjälä
Extract intel_crtc_initial_commit() from intel_initial_commit().
Should make subsequent changes a bit less convoluted.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 96 +++-
1 file changed,
From: Ville Syrjälä
Layer drm_modeset_lock_all_ctx_retry() on top of
drm_modeset_lock_ctx_retry() to make the fairly common
"let's lock everything" pattern nicer.
Currently we have DRM_MODESET_LOCK_ALL_{BEGIN,END}() for this
but I don't really like it due to the magic gotos within,
which makes
From: Ville Syrjälä
Quite a few places are hand rolling the modeset lock backoff dance.
Let's suck that into a helper macro that is easier to use without
forgetting some steps.
The main downside is probably that the implementation of
drm_with_modeset_lock_ctx() is a bit harder to read than a
From: Ville Syrjälä
While staring at some DRM_MODESET_LOCK_ALL_{BEGIN,END}() conversions
I decided I don't really like what those macros do.
The main problems that I see:
- the magic goto inside limits their usefulness to baically
a single statement, unless you're willing to look inside and
On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
>
> On 15/07/2021 12:07, Daniel Vetter wrote:
> > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 15/07/2021 11:15, Matthew Auld wrote:
> >>> From: Chris Wilson
> >>>
> >>> Jason Ekstrand requested a
This is a note to let you know that I've just added the patch titled
drm/ast: Remove reference to struct drm_device.pdev
to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Remove reference to struct drm_device.pdev
to the 5.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Remove reference to struct drm_device.pdev
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 2021-07-15 5:34 a.m., Pekka Paalanen wrote:
> On Wed, 14 Jul 2021 12:13:58 -0400
> Harry Wentland wrote:
>
>> On 2021-07-14 3:35 a.m., Pekka Paalanen wrote:
>>> On Tue, 13 Jul 2021 09:54:35 -0400
>>> Harry Wentland wrote:
>>>
On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
>
Abstract the framebuffer details by mappings its BOs with a call
to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunamp().
Before, the output address with stored as raw pointer in the priv
field of struct drm_writeback_job. Introduce the new type
struct vkms_writeback_job, which holds the output
Abstract the framebuffer details by mapping its BOs with a call
to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunmap().
The call to drm_gem_fb_vmap() ensures that all BOs are mapped
correctly. Gud still only supports single-plane formats.
No functional changes.
Signed-off-by: Thomas Zimmermann
Set the returned mapping address to NULL if a framebuffer plane does
not have a BO associated with it. Likewise, ignore mappings of NULL
during framebuffer unmap operations. Allows users of the functions to
perform unmap operations of certain BOs by themselfes.
Signed-off-by: Thomas Zimmermann
Add the new helpers drm_gem_fb_vmap() and drm_gem_fb_vunmap(), which
provide vmap/vunmap for all BOs of a framebuffer. Convert shadow-
plane helpers, gud and vkms.
Callers of GEM vmap and vunmap functions used to do the minumum work
or get some detail wrong. Therefore shadow-plane helpers were
Move framebuffer vmap code from shadow-buffered plane state into the new
interfaces drm_gem_fb_vmap() and drm_gem_fb_vunmap(). These functions
provide mappings of a framebuffer's BOs into kernel address space. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
DRM uses a magic number of 4 for the maximum number of planes per color
format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the
related code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 14 --
include/drm/drm_fourcc.h
Hi guys,
starting with Linux 5.14-rc1 the framebuffer console on Raspberry Pi 3/4
(no U-Boot, multi_v7_defconfig) isn't available anymore. The display
shows the rainbow screen from the bootloader and than the HDMI screen
goes black instead of kernel messages.
I bisected the issue:
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: ca06f93638362bf83584cdf33897822bf1578cf9
commit: 0eee9977f9d3d8f1e40175dada55b3d00121ac79 [29/30] drm/i915/gem: Roll all
of context creation together
config: x86_64-randconfig-s022-20210715 (attached as .config)
compiler
On Sat, 10 Jul 2021 00:07:22 +0300, Dmitry Baryshkov wrote:
> Restore the assgined-clocks and assigned-clock-parents properties that
> were lost during the txt -> YAML conversion.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../display/msm/dsi-controller-main.yaml| 17 +
On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
>
> Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
> 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
> DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
> image that looks
On Thu, Jul 15, 2021 at 10:37 AM Colin King wrote:
>
> From: Colin Ian King
>
> Don't populate the const array common_rates on the stack but instead it
> static. Makes the object code smaller by 80 bytes:
>
> Before:
>textdata bss dec hex filename
> 268019 98322 256
On 2021-07-15 4:07 p.m., Alex Deucher wrote:
> On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg wrote:
>> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
>>> Hi Dave, Daniel,
>>>
>>> Fixes for 5.14. The big change here is unifying the SMU13 code. This was
>>> new code added in 5.14
09.07.2021 22:31, Thierry Reding пишет:
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index cddee6425461..6ee08e49ec57 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -21,6 +21,7 @@
> #include
> #include
>
> +#include "uapi.h"
09.07.2021 22:31, Thierry Reding пишет:
> diff --git a/drivers/gpu/host1x/fence.c b/drivers/gpu/host1x/fence.c
> new file mode 100644
> index ..06c6b86237bd
> --- /dev/null
> +++ b/drivers/gpu/host1x/fence.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + *
Hi,
On Wed, Jul 14, 2021 at 10:17 AM Douglas Anderson wrote:
>
> Even after the DP AUX backlight on my board worked OK after applying
> the patch ("drm/panel-simple: Power the panel when probing DP AUX
> backlight") [1], I still noticed some strange timeouts being reported
> by
Hi,
On Wed, Jul 14, 2021 at 9:34 AM Douglas Anderson wrote:
>
> When I tried booting up a device that needed the DP AUX backlight, I
> found an error in the logs:
> panel-simple-dp-aux: probe of aux-ti_sn65dsi86.aux.0 failed with error -110
>
> The aux transfers were failing because the panel
On Thu, Jul 15, 2021 at 06:58:31PM +0530, Kirti Wankhede wrote:
> > Review of all the drivers show that they are either already open coding
> > the first/last semantic or are buggy and missing it. All drivers are
> > migrated/fixed to the new open/close_device ops and the unused per-FD
> >
From: Colin Ian King
Don't populate the const array frs_limits on the stack but instead it
static. Makes the object code smaller by 128 bytes:
Before:
textdata bss dec hex filename
251557440 64 326597f93 ./drivers/gpu/drm/bridge/tc358768.o
After:
text
From: Colin Ian King
Don't populate the const array common_rates on the stack but instead it
static. Makes the object code smaller by 80 bytes:
Before:
textdata bss dec hex filename
268019 98322 256 366597 59805 ../display/amdgpu_dm/amdgpu_dm.o
After:
text
On Wed, 14 Jul 2021 at 13:28, Maarten Lankhorst
wrote:
>
> The FIXED mapping is only used for ttm, and tells userspace that the
> mapping type is pre-defined. This disables the other type of mmap
> offsets when discrete memory is used, so fix the selftests as well.
>
> Document the struct as
Am 13.07.21 um 15:59 schrieb Daniel Vetter:
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up
On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg wrote:
>
> Hi Alex,
>
> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > Fixes for 5.14. The big change here is unifying the SMU13 code. This was
> > new code added in 5.14 to support Yellow Carp, but we've
14.07.2021 18:26, Mikko Perttunen пишет:
...
> While my goal of course is to enable proper use of Host1x on the newer
> SoCs, there is absolutely no intention to forget about the older SoCs.
> Observably, to me at least, GR2D and GR3D are working -- the test suites
> are passing (though I did not
Hi,
On Thu, Jul 15, 2021 at 1:02 AM Linus Walleij wrote:
>
> Panels with internal backlight need to assign their backlight member
> directly.
>
> Reported-by: Doug Anderson
> Signed-off-by: Linus Walleij
> ---
> include/drm/drm_panel.h | 5 +++--
> 1 file changed, 3 insertions(+), 2
Hi Dave and Daniel,
I was unsure about the -EDEADLK one based on Daniel's
comment on dri-devel, but Ville's response and the patch
looks reasonable to me. Also they are in sync with the
test cases. So if anything needs to still change on that
area I believe it can be a follow-up work.
Here goes
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #39 from Leandro Jacques (ls...@yahoo.com) ---
(In reply to Alex Deucher from comment #38)
>
> You have a Picasso system. The original bug was about an RX 580. I don't
> think this is the same issue. Sounds like you are seeing
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #34 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297883
--> https://bugzilla.kernel.org/attachment.cgi?id=297883=edit
Linux Firmware version info 20210511.7685cf4
Firmware info as of the moment when the system
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #33 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297881
--> https://bugzilla.kernel.org/attachment.cgi?id=297881=edit
Kernel crash log for linux firmware version 20210511.7685cf4
amdgpu kernel crash log when the
On 7/15/2021 5:50 AM, Jason Gunthorpe wrote:
Prologue:
This is the first series of three to send the "mlx5_vfio_pci" driver that has
been discussed on the list for a while now.
- Reorganize reflck to support splitting vfio_pci
- Split vfio_pci into vfio_pci/vfio_pci_core and provide
Replace pci_enable_device() with pcim_enable_device(),
pci_disable_device() will be called in release automatically.
v2:
use pcim_enable_device()
Signed-off-by: Yang Yingliang
Reported-by: Hulk Robot
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
1 file changed,
On Wed, 14 Jul 2021 at 21:45, Jason Ekstrand wrote:
>
> We don't roll them together entirely because there are still a couple
> cases where we want a separate can_migrate check. For instance, the
> display code checks that you can migrate a buffer to LMEM before it
> accepts it in fb_create.
On Thu, Jul 15, 2021 at 06:49:05AM +0300, Leon Romanovsky wrote:
> On Wed, Jul 14, 2021 at 09:20:31PM -0300, Jason Gunthorpe wrote:
> > From: Max Gurtovoy
> >
> > This pairs with vfio_init_group_dev() and allows undoing any state that is
> > stored in the vfio_device unrelated to registration.
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/dp_mst: Do not set proposed vcpi directly
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Op 15-07-2021 om 12:15 schreef Matthew Auld:
> Add the missing kernel-doc.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
> Cc: Tvrtko Ursulin
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Ramalingam C
> ---
>
1 - 100 of 172 matches
Mail list logo
