On 12/15/21 10:10, Thomas Zimmermann wrote:
[snip]
>
> An extra pointer sounds indeed like over-engineering. If we take ast for
> example, I'd just do something like this:
>
>static ast_pci_register_driver(struct pci_driver *pci)
>{
> if (drm_firmware_drivers_only() &&
On 12/15/2021 8:09 AM, Dmitry Baryshkov wrote:
Implement CRTC's atomic_print_state() callback, printing DPU-specific
CRTC state (LM, CTL and DSPP ids).
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 15 +++
1 file
On 12/10/2021 10:58 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a
On Wed, Dec 15, 2021 at 02:45:56PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A fault injection probe test hit a BUG_ON in a GuC error path. It
> showed that the GuC code could potentially attempt to do many things
> when the device is actually wedged. So, add a check in
On 12/10/2021 10:58 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If GuC encounters an error during engine reset, the i915 driver
promotes to full GT reset. This includes an info message about why the
reset is happening. However, that is not treated as a failure by any
of the CI
On 12/9/2021 4:19 PM, Dmitry Baryshkov wrote:
On 10/12/2021 01:27, Abhinav Kumar wrote:
On 12/9/2021 2:18 PM, Abhinav Kumar wrote:
On 12/1/2021 2:26 PM, Dmitry Baryshkov wrote:
We are preparing to change DPU plane implementation. Move SSPP debugfs
code from dpu_plane.c to
The return value of kmalloc() needs to be checked.
To avoid use in memcpy() in case of the failure of alloc.
Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure
boot"")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 3 +++
1 file
Hello Laurent,
On 12/16/21 00:35, Laurent Pinchart wrote:
[snip]
>>
>> I've built tested with 'make allmodconfig && make M=drivers/gpu/drm/', but
>> only booted in a few devices with and without nomodeset in the cmdline. So
>> testing and reviewing for all the drivers would be highly
On 15/12/2021 20:45, Rob Clark wrote:
From: Rob Clark
We'll re-use this for debugfs.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 28 +++-
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 10 +++
2 files changed, 31 insertions(+), 7
Fix the typo to align with the prototype and function name.
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:631: warning: expecting
prototype for amdgpu_fence_clear_job_fences(). Prototype was for
amdgpu_fence_driver_clear_job_fences() instead
Reported-by:
Quoting Dmitry Baryshkov (2021-12-15 12:02:37)
> On 14/12/2021 22:46, Marijn Suijten wrote:
> > Hi all,
> >
> > On 2021-09-18 16:40:38, Marijn Suijten wrote:
> >> On 2021-09-14 14:44:01, Stephen Boyd wrote:
> >>> Quoting Marijn Suijten (2021-09-11 06:19:19)
> All DSI PHY/PLL drivers were
ang-Rui/drm-amdgpu-introduce-new-amdgpu_fence-object-to-indicate-the-job-embedded-fence/20211215-143731
> git checkout a47becf231b123760625c45242e89f5e5b5b4915
> # save the config file to linux build tree
> mkdir build_dir
> make W=1 O=build_dir ARCH=x86_64
On 12/16/21 01:24, Laurent Pinchart wrote:
> Hi Javier,
>
> On Thu, Dec 16, 2021 at 01:13:56AM +0100, Javier Martinez Canillas wrote:
>> Hello Laurent,
>>
>> On 12/16/21 00:35, Laurent Pinchart wrote:
>>
>> [snip]
>>
I've built tested with 'make allmodconfig && make M=drivers/gpu/drm/',
Hi Javier,
On Thu, Dec 16, 2021 at 01:13:56AM +0100, Javier Martinez Canillas wrote:
> Hello Laurent,
>
> On 12/16/21 00:35, Laurent Pinchart wrote:
>
> [snip]
>
> >>
> >> I've built tested with 'make allmodconfig && make M=drivers/gpu/drm/', but
> >> only booted in a few devices with and
the problematic boards that I have tested is [AMD/ATI] Lexa PRO [Radeon RX 550/550X] ; and the vbios version : 113-RXF9310-C09-BTWhen an exception occurs I can see the following changes in the values of vram size get from RREG32(mmCONFIG_MEMSIZE) ,it seems to have garbage in the upper 16 bits and
The code that uses variable mdss has been removed, So the declaration
and assignment of the variable can be removed.
Eliminate the following clang warning:
drivers/gpu/drm/msm/msm_drv.c:513:19: warning: variable 'mdss' set but
not used [-Wunused-but-set-variable]
Reported-by: Abaci Robot
Hi Dave, Daniel,
Fixes for 5.16.
The following changes since commit 2585cf9dfaaddf00b069673f27bb3f8530e2039c:
Linux 5.16-rc5 (2021-12-12 14:53:01 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.16-2021-12-15
for you to
Hi Javier,
Thank you for the patches.
On Wed, Dec 15, 2021 at 01:59:08AM +0100, Javier Martinez Canillas wrote:
> The nomodeset kernel command line parameter is used to prevent the KMS/DRM
> drivers to be registered/probed. But only a few drivers implement support
> for this parameter and most
On 12/15/2021 8:09 AM, Dmitry Baryshkov wrote:
Implement plane's atomic_print_state() callback, printing DPU-specific
plane state: blending stage, SSPP and multirect mode and index.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
Add the missing layer mixer register dump information to
dpu snapshot to assist debugging.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c:744:35-36:
WARNING comparing pointer to 0.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 2 +-
1 file changed, 1
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard
---
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 286
Hi Marek,
On Wed, Dec 15, 2021 at 5:31 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 15.12.2021 11:15, Jagan Teki wrote:
> > Updated series about drm bridge conversion of exynos dsi.
> > Previous version can be accessible, here [1].
> >
> > Patch 1: connector reset
> >
> > Patch 2:
Hi Chun-Kuang.
Quoting Guillaume Ranquet (2021-12-02 16:31:03)
> Hi Chun-Kuang.
>
> Quoting Chun-Kuang Hu (2021-11-25 16:27:45)
> > Hi, Guillaume:
> >
> > This is a big patch, so I give some comment first.
> >
> > Guillaume Ranquet 於 2021年11月10日 週三 下午9:06寫道：
> > >
> > > From: Markus
On Wed, 15 Dec 2021, Thomas Zimmermann wrote:
> * move DP helper code into dp/ (Jani)
I suggested adding the subdirectory, but I'm going to bikeshed the name,
which I didn't suggest.
$ find drivers/gpu/drm -mindepth 1 -maxdepth 1 -type d | wc -l
68
Assuming we move more of the drm
The "dp_bridge" pointer is allocated with devm_kzalloc() so it will be
freed automatically. Kfreeing it here will only lead to a double free.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable
and disable")
Signed-off-by: Dan Carpenter
---
On Tue, Nov 30, 2021 at 09:29:09AM +0100, Daniel Vetter wrote:
> On Mon, Nov 29, 2021 at 11:07:41AM +0100, Maxime Ripard wrote:
> > On Fri, Nov 26, 2021 at 06:12:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 26, 2021 at 04:43:49PM +0100, Maxime Ripard wrote:
> > > > Hi Daniel,
> > > >
> > >
Introduce vma resources, sort of similar to TTM resources, needed for
asynchronous bind management. Initially we will use them to hold
completion of unbinding when we capture data from a vma, but they will
be used extensively in upcoming patches for asynchronous vma unbinding.
Signed-off-by:
On Wed, Dec 15, 2021 at 12:25:26PM +0200, Laurent Pinchart wrote:
> Hi Geert,
>
> Thank you for the patch.
>
> On Wed, Dec 15, 2021 at 10:27:47AM +0100, Geert Uytterhoeven wrote:
> > The Renesas R-Car Display Unit embedded MIPI DSI encoder is only present
> > on Renesas R-Car V3U SoCs. Hence
Hi Laurent,
On Wed, Dec 15, 2021 at 11:24 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 10:27:45AM +0100, Geert Uytterhoeven wrote:
> > The Renesas R-Car Gen3 and RZ/G2 internal HDMI encoder is only present
> > on Renesas R-Car Gen3 and RZ/G2 SoCs. Hence add a dependency on
> >
On Wed, 15 Dec 2021, Thomas Hellström wrote:
> Since it's starting to be used outside the i915 TTM move code, move it
> to a separate set of files.
Sure, but why the top level instead of gem/?
BR,
Jani.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/Makefile
Hello Zack Rusin,
The patch 8afa13a0583f: "drm/vmwgfx: Implement DRIVER_GEM" from Dec
6, 2021, leads to the following Smatch static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release()
error: uninitialized symbol 'vmw_bo'.
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Huang-Rui/drm-amdgpu-introduce-new-amdgpu_fence-object-to-indicate-the-job-embedded-fence/20211215-143731
base: git://anongit.freedesktop.org/drm/drm drm-next
On Wed, Dec 15, 2021 at 01:43:54PM +0100, Maxime Ripard wrote:
> The drm_hdmi_avi_infoframe_colorspace() function actually sets the
> colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
> structure with DRM_MODE_COLORIMETRY_* values.
>
> To make things worse, the
When introducing asynchronous unbinding, the vma itself may no longer
be alive when the actual binding or unbinding takes place.
Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource
instead of a struct i915_vma for the bind_vma() and unbind_vma() ops.
Similarly change the
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should be coalesced with the migration blit
fence to
There is always a struct vma_resource guaranteed to be alive when we
access a corresponding struct vma_snapshot.
So ditch the latter and instead of allocating vma_snapshots, reference
the already existning vma_resource.
This requires a couple of extra members in struct vma_resource but that's
a
Hi Dave and Daniel,
First, a heads up that I will be on vacation for the next weeks
so Jani will cover the drm-intel-fixes for the next rounds.
Now, here goes drm-intel-fixes-2021-12-15:
Fix a bound check in the DMC fw load.
Thanks,
Rodrigo.
The following changes since commit
Am 15.12.21 um 07:35 schrieb Huang Rui:
The job embedded fence donesn't initialize the flags at
dma_fence_init(). Then we will go a wrong way in
amdgpu_fence_get_timeline_name callback and trigger a null pointer panic
once we enabled the trace event here. So introduce new amdgpu_fence
object to
The drm_hdmi_avi_infoframe_colorspace() function actually sets the
colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
structure with DRM_MODE_COLORIMETRY_* values.
To make things worse, the hdmi_avi_infoframe structure also has a
colorspace field used to signal whether an RGB
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Hi,
This is another attempt at supporting the HDMI YUV output in the vc4 HDMI
driver.
This is a follow-up of
https://lore.kernel.org/dri-devel/20210317154352.732095-1-max...@cerno.tech/
And the discussions that occured recently on the mailing lists and IRC about
this.
The series mentioned
The current code, when parsing the EDID Deep Color depths, that the
YUV422 cannot be used, referring to the HDMI 1.3 Specification.
This specification, in its section 6.2.4, indeed states:
For each supported Deep Color mode, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
1 file changed, 34 insertions(+), 15
On Thu, Dec 9, 2021 at 3:24 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Thu, Dec 9, 2021 at 9:24 PM Lucas Stach wrote:
> >
> > Am Donnerstag, dem 09.12.2021 um 18:09 +0100 schrieb Michael Nazzareno
> > Trimarchi:
> > > Hi Tim
> > >
> > > On Thu, Dec 9, 2021 at 5:40 PM Tim Harvey wrote:
Hi Laurent,
On Wed, Dec 15, 2021 at 12:02 PM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 11:47:27AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > > > On Wed, Dec 15,
On Wed, Dec 15, 2021 at 01:43:53PM +0100, Maxime Ripard wrote:
> The current code, when parsing the EDID Deep Color depths, that the
> YUV422 cannot be used, referring to the HDMI 1.3 Specification.
>
> This specification, in its section 6.2.4, indeed states:
>
> For each supported Deep Color
Hi Stephen, Mike,
On Tue, Sep 14, 2021 at 11:35:12AM +0200, Maxime Ripard wrote:
> Hi,
>
> This is a follow-up of the discussion here:
> https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
>
> This implements a mechanism to raise and lower clock rates based on consumer
>
Hi Geert,
On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 10:27:46AM +0100, Geert Uytterhoeven wrote:
> > > > The
Hi Geert,
Thank you for the patch.
On Wed, Dec 15, 2021 at 10:27:45AM +0100, Geert Uytterhoeven wrote:
> The Renesas R-Car Gen3 and RZ/G2 internal HDMI encoder is only present
> on Renesas R-Car Gen3 and RZ/G2 SoCs. Hence add a dependency on
> ARCH_RENESAS, to prevent asking the user about this
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 181 +-
Protect updates of struct i915_vma flags and async binding / unbinding
with the vm::mutex. This means that i915_vma_bind() needs to assert
vm::mutex held. In order to make that possible drop the caching of
kmap_atomic() maps around i915_vma_bind().
An alternative would be to use kmap_local() but
Since the gt migration code was using only a single fence for
dependencies, these were collected in a dma_fence_array. However, it
turns out that it's illegal to use some dma_fences in a dma_fence_array,
in particular other dma_fence_arrays and dma_fence_chains, and this
causes trouble for us
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is
Move all public DisplayPort headers into dp and update users. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 4 ++--
Move drm_dp_aux_bus.c and its header file into the DP subdirectory
and update all users. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Makefile | 2 --
drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
Split-off DisplayPort functions from KMS helper library and move them
into their own module. Reduces the size of drm_kms_helper.ko by ~50%.
This patchset is part of an on-going effort to reduce the minimum
binary size of the DRM core and helpers. It's helpful for systems with
early-boot DRM
Fix coding style.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index f3d79eda94bb..7f0ff96261cf 100644
---
Split the DP declarations from other helpers before moving the
DP functions into a separate module.
v2:
* forward-declare struct drm_dp_aux (Jani)
* add include guards in drm_dp_helper_internal.h
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_crtc_helper_internal.h |
Move DisplayPort functions into a separate module to reduce the size
of the KMS helpers. Select DRM_DP_HELPER for all users of the code. To
avoid naming conflicts, rename drm_dp_helper.c to drm_dp.c
This change can help to reduce the size of the kernel binary. Some
numbers from a x86-64 test
Hi Geert,
On Wed, Dec 15, 2021 at 11:47:27AM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > > On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed,
Hi
Am 15.12.21 um 12:04 schrieb Jani Nikula:
On Wed, 15 Dec 2021, Thomas Zimmermann wrote:
* move DP helper code into dp/ (Jani)
I suggested adding the subdirectory, but I'm going to bikeshed the name,
which I didn't suggest.
$ find drivers/gpu/drm -mindepth 1 -maxdepth 1 -type d |
Hello Kevin Tang,
This is a semi-automatic email about new static checker warnings.
The patch 43531edd53f0: "drm/sprd: add Unisoc's drm kms master" from
Dec 7, 2021, leads to the following Smatch complaint:
drivers/gpu/drm/sprd/sprd_drm.c:158 sprd_drm_shutdown()
error: we previously
Hi
Am 12.12.21 um 07:24 schrieb Hector Martin:
Hi DRM folks,
This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.
This avoids
Hi Hsin-Yi,
Quoting Hsin-Yi Wang (2021-12-09 07:29:30)
> On Wed, Nov 10, 2021 at 9:08 PM Guillaume Ranquet
> wrote:
> >
> > From: Markus Schneider-Pargmann
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
> > according phy driver mediatek-dp-phy.
> >
> > It
From: Arnd Bergmann
On architectures with size_t different from 'unsigned long', gcc
prints this warning:
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info':
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:40: error: format '%ld' expects
argument of type 'long int', but argument 4
Il 15/12/21 07:15, Yunfei Dong ha scritto:
This series adds support for multi hardware decode into mtk-vcodec, by first
adding use
of_platform_populate to manage each hardware information: interrupt, clock,
register
bases and power. Secondly add core work queue to deal with core hardware
Hi Laurent,
On Wed, Dec 15, 2021 at 11:30 AM Laurent Pinchart
wrote:
> On Wed, Dec 15, 2021 at 12:23:39PM +0200, Laurent Pinchart wrote:
> > On Wed, Dec 15, 2021 at 11:17:37AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Dec 15, 2021 at 11:12 AM Laurent Pinchart wrote:
> > > > On Wed, Dec 15,
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 23 ---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 8 +++
Ditch the writeback hook and drop i915_gem_object_writeback(). We
already support the shrinker_release_pages hook which can just call
shmem_writeback directly.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.h
Hi Jagan,
On 15.12.2021 11:15, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
> Previous version can be accessible, here [1].
>
> Patch 1: connector reset
>
> Patch 2: panel_bridge API
>
> Patch 3: Bridge conversion
>
> Patch 4: Atomic functions
>
> Patch 5:
Hi Angelo,
Quoting AngeloGioacchino Del Regno (2021-12-10 11:17:44)
> Il 10/11/21 14:06, Guillaume Ranquet ha scritto:
> > From: Markus Schneider-Pargmann
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
> > according phy driver mediatek-dp-phy.
> >
> > It supports
On Wed, Dec 01, 2021 at 04:31:00PM +0100, Thomas Zimmermann wrote:
> Update the connector code to fail if the connector could not be
> initialized. The current code just ignored the error and failed
> later when the connector was supposed to be used.
>
> Signed-off-by: Thomas Zimmermann
Hi,
On Wed, Dec 15, 2021 at 09:03:01AM -0600, Guillaume Ranquet wrote:
> Quoting Maxime Ripard (2021-12-13 17:54:22)
> > On Thu, Dec 02, 2021 at 06:48:12AM -0800, Guillaume Ranquet wrote:
> > > Hi,
> > >
> > > Quoting Maxime Ripard (2021-11-25 15:30:34)
> > > > On Wed, Nov 24, 2021 at 01:45:21PM
your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-Asynchronous-vma-unbinding/20211215-1
On 09/12/2021 17:45, Ramalingam C wrote:
From: Mika Kahola
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
Signed-off-by: Mika Kahola
cc: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
On Wed, Dec 15, 2021 at 10:02:22AM -0600, Guillaume Ranquet wrote:
> Quoting Maxime Ripard (2021-12-15 16:15:08)
> > Hi,
> >
> > On Wed, Dec 15, 2021 at 09:03:01AM -0600, Guillaume Ranquet wrote:
> > > Quoting Maxime Ripard (2021-12-13 17:54:22)
> > > > On Thu, Dec 02, 2021 at 06:48:12AM -0800,
Hi
Am 15.12.21 um 10:17 schrieb Maxime Ripard:
From: Dave Stevenson
Adds a format that is 3 10bit YUV 4:2:0 samples packed into
a 32bit word (with 2 spare bits).
Supported on Broadcom BCM2711 chips.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Hi Marek,
On Wed, Dec 15, 2021 at 7:49 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 15.12.2021 13:57, Jagan Teki wrote:
> > On Wed, Dec 15, 2021 at 5:31 PM Marek Szyprowski
> > wrote:
> >> On 15.12.2021 11:15, Jagan Teki wrote:
> >>> Updated series about drm bridge conversion of exynos dsi.
On Wed, Dec 01, 2021 at 04:30:58PM +0100, Thomas Zimmermann wrote:
> I2C initialization is allowed to fail. In this case, create a connector
> without DDC adapter. The current code would dereference a NULL pointer.
>
> Reading the modes from the connector is supposed to work without I2C
>
On Wed, Dec 01, 2021 at 04:30:59PM +0100, Thomas Zimmermann wrote:
> Release the I2C adapter as part of the DRM device cleanup.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
Hi
Am 15.12.21 um 10:17 schrieb Maxime Ripard:
From: Dave Stevenson
The BT601/BT709 color encoding and limited vs full
range properties were not being exposed, defaulting
always to BT601 limited range.
Expose the parameters and set the registers appropriately.
Signed-off-by: Dave Stevenson
On Wed, Dec 01, 2021 at 02:23:07AM +0300, Dmitry Osipenko wrote:
> This series adds runtime PM support to Tegra drivers and enables core
> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>
> All patches in this series are interdependent and should go via Tegra tree
> for
On 15/12/2021 11:07, Matthew Auld wrote:
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Looks good to me - but since it touches TTM I leave for Thomas to approve.
Regards,
Tvrtko
P.S. I hope writing the patch means you thought it is an
Hi,
I'm looking for some advice/guidance on an issue I've run into with the IMX DRM
implementation with LVDS. I'm using an imx6q with an 1080p LVDS display on
kernel 5.10.73-rt. When running Qt applications (EGLFS) with this platform,
I've run into a strange issue where the framebuffer flip
On Wed, Dec 08, 2021 at 04:12:22PM +0100, Sascha Hauer wrote:
> The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
> The binding differs slightly from the existing VOP binding, so add a new
> binding file for it.
>
> Signed-off-by: Sascha Hauer
> ---
>
Where no modifiers are exposed, usually linear modifier is assumed.
However, userspace code is starting to expect IN_FORMATS even when the
only supported modifiers are linear [1].
To avoid possible issues, explicitly set the DRM_FORMAT_MOD_LINEAR
modifier.
[1]
Hi Yunfei,
Le mercredi 15 décembre 2021 à 14:59 +0800, Yunfei Dong a écrit :
> From: Yunfei Dong
>
> Adds h264 lat and core driver for mt8192.
This is purely a nit, but I have first notice the usage of "slice" in the
namespace and the title, which lead me to think this new platform was
Properties #address-cells and #size-cells are valid.
The bridge node can also contains panel node.
Signed-off-by: David Heidelberg
---
.../bindings/display/bridge/toshiba,tc358768.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git
Quoting Maxime Ripard (2021-12-15 16:15:08)
> Hi,
>
> On Wed, Dec 15, 2021 at 09:03:01AM -0600, Guillaume Ranquet wrote:
> > Quoting Maxime Ripard (2021-12-13 17:54:22)
> > > On Thu, Dec 02, 2021 at 06:48:12AM -0800, Guillaume Ranquet wrote:
> > > > Hi,
> > > >
> > > > Quoting Maxime Ripard
When dumping plane state also output plane's alpha and blending mode
values to ease debugging of complex composition cases.
Signed-off-by: Dmitry Baryshkov
---
Changes since v1:
- Changed alpha property format to pad with zeroes
---
drivers/gpu/drm/drm_atomic.c| 3 +++
1 - 100 of 218 matches
Mail list logo
