Hi Liu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on robh/for-next drm-intel/for-linux-next
drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next
linus/master v5.12-rc3 next-20210319]
[cannot apply
On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > > These are 16 bits per color channel unsigned normalized formats.
> > > They are supported by at
Hi Maxime,
Thank you for the patch.
On Fri, Mar 19, 2021 at 04:29:20PM +0100, Maxime Ripard wrote:
> Commit 977697e20b3d ("drm/atomic: Pass the full state to planes atomic
> disable and update") added the old_state variable instead of what used
> to be a parameter, but it also removed the sole
Hi,
On Fri, Mar 19, 2021 at 5:54 AM Kalyan Thota wrote:
>
> During crtc disable, display perf structures are reset to 0
> which includes state varibles which are immutable. On crtc
> enable, we use the same structures and they don't refelect
> the actual values
>
> 1) Fix is to avoid updating
I'd love to delete the SINGLE_TIMELINE API because it leaks an
implementation detail of contexts through to the API and is something
that userspace can do itself, trivially. Unfortunately, it's used by
the media driver so we can't do that. We can, however, do the next-best
thing which is to
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 112 ++
This patch series is the second installment of my quest to clean up the
i915 uAPI. The first three patches delete interfaces which have only ever
been used by i-g-t and never any real userspace. In the case of NO_ZEROMAP,
it's unclear exactly how this happened. There were userspace patches for
On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > These are 16 bits per color channel unsigned normalized formats.
> > They are supported by at least AMD display hw, and suitable for
> > direct scanout of Vulkan swapchain
On Fri, Mar 19, 2021 at 5:31 PM Evan Benn wrote:
>
> On Sat, 20 Mar 2021 at 02:10, Harry Wentland wrote:
> > On 2021-03-19 10:22 a.m., Alex Deucher wrote:
> > > On Fri, Mar 19, 2021 at 3:23 AM Evan Benn wrote:
> > >>
> > >> AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
> > >> to
On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 18, 2021 at
Hi Dave, Daniel,
New stuff for 5.13.
The following changes since commit 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371:
drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) (2021-02-18 16:43:09
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > So basically we see this
On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> These are 16 bits per color channel unsigned normalized formats.
> They are supported by at least AMD display hw, and suitable for
> direct scanout of Vulkan swapchain images in the format
> VK_FORMAT_R16G16B16A16_UNORM.
>
>
On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > So basically we see this warning only in case of bigjoiner when
> > > drm_atomic_check gets
This is intended to enable direct high-precision scanout and pageflip
of Vulkan swapchain images in format VK_FORMAT_R16G16B16A16_UNORM.
Expose DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616,
DRM_FORMAT_XBGR16161616 and DRM_FORMAT_ABGR16161616 as 16 bpc
unsigned normalized formats. These allow
This is needed to avoid warnings with linebuffer depth 36 bpp.
Testing on a Polaris11, DCE-11.2 on a 10 bit HDR-10 monitor
showed no obvious problems, and this 12 bpc limit is consistent
with what other function in the DCE bit depth reduction path use.
Signed-off-by: Mario Kleiner
---
Testing with the photometer shows that at least Raven Ridge DCN-1.0
does not achieve more than 10 bpc effective output precision with a
16 bpc unorm surface of type SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616,
unless linebuffer depth is increased from LB_PIXEL_DEPTH_30BPP to
LB_PIXEL_DEPTH_36BPP.
These are 16 bits per color channel unsigned normalized formats.
They are supported by at least AMD display hw, and suitable for
direct scanout of Vulkan swapchain images in the format
VK_FORMAT_R16G16B16A16_UNORM.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_fourcc.c | 4
Add the necessary format definition, bandwidth and pixel size mappings,
prescaler setup, and pixelformat selection, following the logic
already present for SURFACE_PIXEL_FORMAT_GRPH_ARGB16161616.
The new SURFACE_PIXEL_FORMAT_GRPH_ABGR16161616 is implemented as the
old
Hi,
this patch series adds the fourcc's for 16 bit fixed point unorm
framebuffers to the core, and then an implementation for AMD gpu's
with DisplayCore.
This is intended to allow for pageflipping to, and direct scanout of,
Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM.
I
On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > So basically we see this warning only in case of bigjoiner when
> > drm_atomic_check gets called without setting the state->allow_modeset flag.
>
> Considering the
On 2021-03-19 8:49 a.m., Maxime Ripard wrote:
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it
This caused a regression in kfdtest in a large-buffer stress test after
memory allocation for user pages fails:
[17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16
[17359.543746] BUG: kernel NULL pointer dereference, address:
[17359.551494] #PF: supervisor
On Friday, March 19th, 2021 at 8:06 PM, Lucas Stach
wrote:
> +/*
> + * Vivante TS (tile-status) buffer modifiers. They can be combined with all
> of
> + * the color buffer tiling modifiers defined above. When TS is present it's a
> + * separate buffer containing the clear/compression status of
On Fri, Mar 19, 2021 at 8:06 PM Lucas Stach wrote:
>
> Vivante TS (tile-status) buffer modifiers. They can be combined with all of
> the Vivante color buffer tiling modifiers, so they are kind of a modifier
> modifier. If a TS modifier is present we have a additional plane for the
> TS buffer and
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #12 from Bat Malin (bat_ma...@abv.bg) ---
Old Kernel e.g. 5.10.23 initializes this
1.038643] [drm] DM_PPLIB: values for Engine clock
[1.038645] [drm] DM_PPLIB: 214000
[1.038646] [drm] DM_PPLIB: 603000
[1.038646] [drm]
On Fri, Mar 19, 2021 at 2:47 PM Christian König
wrote:
>
>
>
> Am 19.03.21 um 19:26 schrieb Harry Wentland:
> > On 2021-03-19 2:13 p.m., Alex Deucher wrote:
> >> + Harry, Nick
> >>
> >> On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
> >>>
> >>> Fixes the following W=1 kernel build warning(s):
On Mon, Mar 01, 2021 at 02:26:01AM -0800, John Hubbard wrote:
> On 3/1/21 01:52, Daniel Vetter wrote:
> > There's no mmu notifier or anything like that, releasing this pin is
> > entirely up to userspace. Hence FOLL_LONGTERM.
> >
> > No cc: stable for this patch since a lot of the infrastructure
Am Freitag, dem 19.03.2021 um 20:09 +0100 schrieb Daniel Vetter:
> On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote:
> > Nothing checks userptr.ro except this call to pup_fast, which means
> > there's nothing actually preventing userspace from writing to this.
> > Which means you can
On Mon, Mar 01, 2021 at 10:52:53AM +0100, Daniel Vetter wrote:
> Nothing checks userptr.ro except this call to pup_fast, which means
> there's nothing actually preventing userspace from writing to this.
> Which means you can just read-only mmap any file you want, userptr it
> and then write to it
On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> > > Don't print a warning when we fail to allocate a page for swapping things
> > > out.
> > >
> > > Also rely on
Vivante TS (tile-status) buffer modifiers. They can be combined with all of
the Vivante color buffer tiling modifiers, so they are kind of a modifier
modifier. If a TS modifier is present we have a additional plane for the
TS buffer and the modifier defines the layout of this TS buffer.
The current calculation based on the required_dma mask can be significantly
off, so that the linear window only overlaps a small part of the DRAM
address space. This can lead to the command buffer being unmappable, which
is obviously bad.
Rework the linear window offset calculation to be based on
From: Sascha Hauer
This is the 3D GPU found on the i.MX8MP SoC. The feature bits are
taken from the NXP downstream kernel driver 6.4.3.p1.305572.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed,
Am 19.03.21 um 18:52 schrieb Daniel Vetter:
On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
Don't print a warning when we fail to allocate a page for swapping things out.
Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Uh this part doesn't make
Am 19.03.21 um 19:26 schrieb Harry Wentland:
On 2021-03-19 2:13 p.m., Alex Deucher wrote:
+ Harry, Nick
On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In
function
On Fri, Mar 19, 2021 at 2:26 PM Harry Wentland wrote:
>
> On 2021-03-19 2:13 p.m., Alex Deucher wrote:
> > + Harry, Nick
> >
> > On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
> >>
> >> Fixes the following W=1 kernel build warning(s):
> >>
> >>
On 2021-03-19 2:13 p.m., Alex Deucher wrote:
+ Harry, Nick
On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function
‘calculate_bandwidth’:
On 2021-03-19 4:24 a.m., Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17:
warning: no previous prototype for ‘dce80_aux_engine_create’
[-Wmissing-prototypes]
On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17:
> warning: no previous prototype for ‘dce80_aux_engine_create’
> [-Wmissing-prototypes]
>
On 1/24/21 6:04 PM, Marek Vasut wrote:
On 12/24/20 7:18 AM, Marek Vasut wrote:
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pixelclk-active",
same as the one used by display timings, and configure bus flags
+ Harry, Nick
On Fri, Mar 19, 2021 at 4:24 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function
> ‘calculate_bandwidth’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1:
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote:
> On Thu, 18 Mar 2021, Daniel Vetter wrote:
>
> > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
> > >
> > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> > > >
> > > > On Thu, 11 Mar 2021, Lee Jones wrote:
> > > >
> > > > >
On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> Don't print a warning when we fail to allocate a page for swapping things out.
>
> Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Uh this part doesn't make sense. Especially since you only do it for
Reviewed-by: Lyude Paul
On Fri, 2021-03-19 at 08:24 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David
[AMD Official Use Only - Internal Distribution Only]
+ Leo
From: amd-gfx on behalf of Christian
König
Sent: Friday, March 19, 2021 10:08 AM
To: Liu, Leo ; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: stop warning
On Fri, Mar 19, 2021 at 12:13 PM Fabio Estevam wrote:
> Thanks for the feedback.
> I will follow the same approach for fixing the suspend/resume path then.
>
> Let me test it and then I will re-submit Dmitry's patch and the one
> for suspend/resume as part of a patch series.
This approach works
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[]
From: Dmitry Baryshkov
If GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
Hey Sia,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 12 Mar 2021 at 10:09, Sia Jee Heng wrote:
>
> Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI
> audio driver can accept the IEC958 data from the I2S input.
>
> Signed-off-by: Sia Jee Heng
Hi,
On 3/1/21 4:43 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> The backlight still turns back on
Commit 977697e20b3d ("drm/atomic: Pass the full state to planes atomic
disable and update") added the old_state variable instead of what used
to be a parameter, but it also removed the sole user of that variable in
the vop_plane_atomic_update function leading to an usused variable.
Remove it.
On Fri, Mar 19, 2021 at 8:13 AM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Fri, Mar 19, 2021 at 11:44 AM Rob Clark wrote:
>
> > I think that might not help if something fails to probe due to (for
> > example) a missing dependency, so !priv->kms is probably a better
> > check to cover both cases.
Hi Rob,
On Fri, Mar 19, 2021 at 11:44 AM Rob Clark wrote:
> I think that might not help if something fails to probe due to (for
> example) a missing dependency, so !priv->kms is probably a better
> check to cover both cases. But the 2nd patch makes a good point, that
> the suspend/resume path
On 2021-03-19 10:22 a.m., Alex Deucher wrote:
On Fri, Mar 19, 2021 at 3:23 AM Evan Benn wrote:
AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
to ensure no display backlight will flicker at low user brightness
settings. However this value is quite bright, so for devices that do
On Wed, Mar 17, 2021 at 9:27 AM Yang Li wrote:
>
> This fixes the following sparse warnings:
> drivers/gpu/drm/gma500/psb_drv.c:303:56: warning: Using plain integer as
> NULL pointer
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Applied to drm-misc-next
Thanks
Patrik
> ---
>
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc3 next-20210319]
[cannot apply to anholt/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> So basically we see this warning only in case of bigjoiner when
> drm_atomic_check gets called without setting the state->allow_modeset flag.
Considering the code is 'WARN(!state->allow_modeset, ...' that
fact should be rather
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Just another drive-by fix I noticed while going through the tree to cleanup
> DP aux adapter registration - make sure we unregister the DP AUX dev if
>
On Fri, Mar 19, 2021 at 5:09 AM Fabio Estevam wrote:
>
> Hi Dmitry,
>
> On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov
> wrote:
>
> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> > b/drivers/gpu/drm/msm/msm_atomic.c
> > index 6a326761dc4a..2fd0cf6421ad 100644
> > ---
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another drive-by fix I found when fixing DP AUX adapter across the kernel
> tree - make sure we don't leak resources (and by proxy-AUX adapters) on
> failures in
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another case of linking an encoder to a connector after the connector's
> been registered. The proper place to do this is before connector
> registration, so
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another driver I found that seems to forget to unregister it's DP AUX
> device. Let's fix this by adding anx6345_bridge_detach().
>
> Signed-off-by: Lyude Paul
>
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Just another issue I noticed while correcting usages of
> drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
> steps in
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since encoder mappings for connectors are exposed to userspace, we should
> be attaching the encoder before exposing the connector to userspace. Just a
> drive-by
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Surprisingly, this bridge actually registers it's AUX adapter at the
> correct time already. Nice job! However, it does forget to actually
> unregister the AUX
Hey Lyude,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since this is a bridge, we don't start out with a respective DRM device.
> Likewise this means we don't have a connector, which also means that we
> should be following
On Fri, Mar 19, 2021 at 3:23 AM Evan Benn wrote:
>
> AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
> to ensure no display backlight will flicker at low user brightness
> settings. However this value is quite bright, so for devices that do not
> implement the ACPI ATIF
>
Don't print a warning when we fail to allocate a page for swapping things out.
Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_tt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On Fri, Mar 19, 2021 at 08:24:13AM +, Lee Jones wrote:
> In the macro for_each_oldnew_plane_in_state() 'new_plane_state' is provided
> as a container for state->planes[i].new_state, but is not utilised in
> some use-cases, so we fake-use it instead.
>
> Fixes the following W=1 kernel build
https://bugzilla.kernel.org/show_bug.cgi?id=212361
Bug ID: 212361
Summary: WARNING: CPU: 0 PID: 411 at
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21
/rn_clk_mgr.c:833 rn_clk_mgr_construct+0x2dd/0x440
From: Thierry Reding
The SOR resets are exclusively shared with the SOR power domain. This
means that exclusive access can only be granted temporarily and in order
for that to work, a rigorous sequence must be observed. To ensure that a
single consumer gets exclusive access to a reset, each
On 2021-03-18 23:47, Dario Binacchi wrote:
Il 17/03/2021 09:19 Tomi Valkeinen ha scritto:
On 14/03/2021 17:13, Dario Binacchi wrote:
> As reported by TI spruh73x RM, the LCD pixel clock (LCD_PCLK) frequency
> is obtained by dividing LCD_CLK, the LCD controller reference clock,
> for CLKDIV:
>
During crtc disable, display perf structures are reset to 0
which includes state varibles which are immutable. On crtc
enable, we use the same structures and they don't refelect
the actual values
1) Fix is to avoid updating the state structures during disable.
2) Reset the perf structures during
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Signed-off-by: Maxime Ripard
---
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 53 ++
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ++
2 files
Am 19.03.21 um 05:32 schrieb Huang Rui:
On Thu, Mar 18, 2021 at 08:47:19PM +0800, Christian König wrote:
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
Hi Dmitry,
On Mon, Mar 1, 2021 at 6:41 PM Dmitry Baryshkov
wrote:
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 6a326761dc4a..2fd0cf6421ad 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -207,7 +207,12
General question for the audience: Is there any way to silence the build
bot here?
This is a well known false positive.
Regards,
Christian.
Am 18.03.21 um 19:13 schrieb kernel test robot:
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
19.03.2021 10:06, Thierry Reding пишет:
> From: Thierry Reding
>
> Coupling of display controllers used to rely on runtime PM to take the
> companion controller out of reset. Commit fd67e9c6ed5a ("drm/tegra: Do
> not implement runtime PM") accidentally broke this when runtime PM was
> removed.
>
Hey Lyude,
Thanks for the patch
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> And finally, convert all of the code in drm_dp_mst_topology.c over to using
> drm_err() and drm_dbg*(). Note that this refactor would have been a lot
> more complicated to have tried writing a coccinelle script
Hey Lyude,
Thanks for the patch.
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> Now that we've added a back-pointer to drm_device to drm_dp_aux, made
> drm_dp_aux available to any functions in drm_dp_helper.c which need to
> print to the kernel log, and ensured all of our logging uses a
Hey Lyude,
Thanks for the patch.
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> Since this is one of the few functions in drm_dp_mst_topology.c that
> doesn't have any way of getting access to a drm_device, let's pass the
> drm_dp_mst_topology_mgr down to this function so that it can use
>
Hey Lyude,
Thanks for the patch,
On Fri, 19 Feb 2021 at 22:59, Lyude Paul wrote:
>
> Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
> to make sure that we can also add ratelimited versions of these macros in
> order to retain some of the previous debugging output
Hi Jernej,
On Thu, Mar 18, 2021 at 07:16:33PM +0100, Jernej Škrabec wrote:
> Dne sreda, 17. marec 2021 ob 16:43:34 CET je Maxime Ripard napisal(a):
> > Hi,
> >
> > Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
> > the RaspberryPi4.
> >
> > I took the same approach
On Fri, 19 Mar 2021, Bhaskar Chowdhury wrote:
> s/nothign/nothing/
>
> Signed-off-by: Bhaskar Chowdhury
Thanks, pushed.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, Mar 19, 2021 at 10:44:56AM +0100, Neil Armstrong wrote:
> On 18/03/2021 19:31, Jernej Škrabec wrote:
> > Dne sreda, 17. marec 2021 ob 17:08:07 CET je Neil Armstrong napisal(a):
> >> On 17/03/2021 16:43, Maxime Ripard wrote:
> >>> The atomic_get_output_bus_fmts bridge callback is there to
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous
> prototype for ‘headc57d_olut’ [-Wmissing-prototypes]
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
>
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or
> member 'crtc' not described in 'nv_crtc_mode_set_regs'
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning:
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand *
> file mga_ioc32.c
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc:
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or
> member 'filp' not described in 'nouveau_compat_ioctl'
> drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning:
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’:
> drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: variable ‘dev’ set
> but not used
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following build error:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for
> ‘nv50_display_fini’
> In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:71:
>
On Fri, Mar 19, 2021 at 9:25 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function
> parameter or member 'gr' not described in 'gf100_gr_wait_idle'
>
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel
On Fri, Mar 19, 2021 at 9:24 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function
> parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_voltage'
>
Reviewed-by: Karol Herbst
On Fri, Mar 19, 2021 at 9:24 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
>
[Bug][AST2500]
V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset mode is mainly designed for ARM ICE debugger.
1 - 100 of 141 matches
Mail list logo
