Quoting Sankeerth Billakanti (2021-10-27 18:54:48)
> DP driver needs a 10 second delay before phy_init so that
> the usb combo phy initializes and sets up the necessary
> clocks for usb devices such as keyboard and mouse.
>
> eDP controller uses a standalone phy and need not wait for
> phy initiali
Quoting Sankeerth Billakanti (2021-10-27 18:54:47)
> The eDP sink on sc7280 supports ASSR and dp driver will
> enable ASSR in the source hardware. The driver needs to
> enable the ASSR field in the DPCD configuration register
> to avoid screen corruption. This change will enable ASSR
> if supported
Quoting Sankeerth Billakanti (2021-10-27 18:54:46)
> The sc7280 eDP sink that supports downspread will fail link training
> if source does not enable SSC / downspread. This change will set the
> downspread bit in the DP sink if supported and indicate SSC support
> to the DP PHY driver.
>
> Signed-o
On Wed, Oct 27, 2021 at 03:45:40PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
> Reported-by: kernel test robot
> ---
> V1 -> V2: Initializing variable and simplyfing conditi
Quoting Sankeerth Billakanti (2021-10-27 18:54:45)
> Add a macro to check for the max_downspread capability in
> drm_dp_helper.
>
> Signed-off-by: Sankeerth Billakanti
> ---
Looks OK to me. One question below
Reviewed-by: Stephen Boyd
> include/drm/drm_dp_helper.h | 6 ++
> 1 file changed
Quoting Sankeerth Billakanti (2021-10-27 18:54:44)
> The eDP controller on SC7280 is similar to the eDP/DP controllers
> supported by the current driver implementation.
>
> SC7280 supports one EDP and one DP controller which can operate
> concurrently.
>
> This change adds the support for eDP and D
Quoting Sankeerth Billakanti (2021-10-27 18:54:43)
> From: Sankeerth Billakanti
>
> The Qualcomm SC7280 platform supports one eDP controller
> and a DP controller. This change will add the compatible
> string for both eDP and DP to msm dp-controller binding.
>
> Signed-off-by: Sankeerth Billakanti
Thanks Sam, I've meanwhile merged the patch with our R-b.
Am 26.10.21 um 20:46 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Oct 26, 2021 at 07:57:00PM +0200, Thomas Zimmermann wrote:
Linking the CMA frambuffer helpers into a CMA helper library in
commit 4b2b5e142ff4 ("drm: Move GEM memory managers
On Wed, Oct 27, 2021 at 11:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the amdgpu tree got conflicts in:
>
> drivers/gpu/drm/amd/display/dc/core/dc_link.c
> drivers/gpu/drm/drm_dp_mst_topology.c
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>
> between com
Hi Chun-Kuang,
On Thu, Oct 28, 2021 at 7:47 AM Chun-Kuang Hu wrote:
>
> Hi, Fei:
>
> Fei Shao 於 2021年10月27日 週三 下午5:32寫道：
> >
> > Hi Jason,
> >
> > On Wed, Oct 27, 2021 at 10:19 AM jason-jh.lin
> > wrote:
> > >
> > > From: Chun-Kuang Hu
> > >
> > > CMDQ is used to update display register in vb
Hi all,
Today's linux-next merge of the amdgpu tree got conflicts in:
drivers/gpu/drm/amd/display/dc/core/dc_link.c
drivers/gpu/drm/drm_dp_mst_topology.c
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
between commits:
d740e0bf8ed4 ("drm/amd/display: Add DP 2.0 MST DC Support")
4172
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/kmb/kmb_drv.c
between commit:
c026565fe9be ("drm/kmb: Enable alpha blended second plane")
from Linus' tree and commit:
099afadc533f ("drm/kmb: Enable support for framebuffer console")
from the drm-
Hi Dave, Daniel,
Fixes for 5.15.
The following changes since commit defbbcd99fa68cb7feed453662048baa87e9a441:
Merge tag 'amd-drm-fixes-5.15-2021-10-21' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-10-27 10:01:21
+1000)
are available in the Git repository at:
https:/
On Wed, 2021-10-27 at 10:48 +0100, Matthew Auld wrote:
> On Wed, 27 Oct 2021 at 10:44, Jani Nikula
> wrote:
> >
> > On Wed, 27 Oct 2021, Matthew Auld
> > wrote:
> > > On Wed, 27 Oct 2021 at 09:58, Jani Nikula
> > > wrote:
> > > >
> > > > On Wed, 27 Oct 2021, Matthew Auld
> > > > wrote:
> > >
On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote:
> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple:
> > MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
> > source page was already locked during migrate_vma_collect(). If it
> > wasn't then the a second a
On Tuesday, 26 October 2021 11:57:06 AM AEDT Ralph Campbell wrote:
>
> On 10/24/21 21:16, Alistair Popple wrote:
> > MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
> > source page was already locked during migrate_vma_collect(). If it
> > wasn't then the a second attempt is
Using swap() make it more readable.
Reported-by: Zeal Robot
Signed-off-by: Yang Guang
---
drivers/video/fbdev/sis/sis_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index 266a5582f94d..742f62986
topic/amdgpu-dp2.0-mst-2021-10-27:
UAPI Changes:
Nope!
Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is
Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...
Driver Changes:
...
Hi Alexander,
Thank you for the patch.
On Tue, Oct 19, 2021 at 08:52:39AM +0200, Alexander Stein wrote:
> VCC needs to be enabled before releasing the enable GPIO.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Alexander Stein
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti
Hi, Fei:
Fei Shao 於 2021年10月27日 週三 下午5:32寫道：
>
> Hi Jason,
>
> On Wed, Oct 27, 2021 at 10:19 AM jason-jh.lin
> wrote:
> >
> > From: Chun-Kuang Hu
> >
> > CMDQ is used to update display register in vblank period, so
> > it should be execute in next 2 vblank. One vblank interrupt
> > before send
Hi Alexander,
Thank you for the patch.
On Tue, Oct 19, 2021 at 08:52:38AM +0200, Alexander Stein wrote:
> Add a VCC regulator which needs to be enabled before the EN pin is
> released.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Alexander Stein
> ---
> .../devicetree/bindings/display/bridg
Hi, Jason:
jason-jh.lin 於 2021年10月27日 週三 上午10:19寫道：
>
> From: Chun-Kuang Hu
>
> One mtk_crtc need just one cmdq_handle, so add one cmdq_handle
> in mtk_crtc to prevent frequently allocation and free of
> cmdq_handle.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Chun-Kuang Hu
> Signed-off-by
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits.
They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10
and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the
same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern
permutations).
These
Hi, Jason:
jason-jh.lin 於 2021年10月27日 週三 上午10:19寫道：
>
> Add mbox_free_channel in mtk_drm_crtc_destroy.
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/driver
Reviewed-by: Lyude Paul
Will add to the topic branch right now
On Wed, 2021-10-27 at 18:39 -0400, Alex Deucher wrote:
> Need to guard some things with CONFIG_DRM_AMD_DC_DCN.
>
> Fixes: 41724ea273cdda ("drm/amd/display: Add DP 2.0 MST DM Support")
> Signed-off-by: Alex Deucher
> Cc: Lyude Paul
Need to guard some things with CONFIG_DRM_AMD_DC_DCN.
Fixes: 41724ea273cdda ("drm/amd/display: Add DP 2.0 MST DM Support")
Signed-off-by: Alex Deucher
Cc: Lyude Paul
Cc: Dave Airlie
---
Lyude, can you apply this to topic/amdgpu-dp2.0-mst? or Dave, if it's
already pulled can you apply this to d
Hi Doug,
On Wed, Oct 27, 2021 at 3:08 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Oct 26, 2021 at 2:56 PM Philip Chen wrote:
> >
> > Fit ps8640 driver into runtime power management framework:
> >
> > First, break _poweron() to 3 parts: (1) turn on power and wait for
> > ps8640's internal MCU to
Hi Doug
On Wed, Oct 27, 2021 at 3:13 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Oct 26, 2021 at 2:56 PM Philip Chen wrote:
> >
> > Conventionally, panel is listed under the root of the device tree.
> > When userland asks for display mode, ps8640 bridge is responsible
> > for returning EDID when
Hi,
On Wed, Oct 27, 2021 at 3:07 PM Doug Anderson wrote:
>
> This will also cause a conflict when Sam's change lands [1] so I guess
> we can see whose lands first. Let me review that now and maybe you add
> a Tested-by? If it lands that'll make it easier and you can just
> rebase on both of them?
Hi,
On Tue, Oct 26, 2021 at 2:56 PM Philip Chen wrote:
>
> Conventionally, panel is listed under the root of the device tree.
> When userland asks for display mode, ps8640 bridge is responsible
> for returning EDID when ps8640_bridge_get_edid() is called.
>
> Now enable a new option of listing pa
Hi "Thomas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.15-rc7
next-20211027]
[If your patch is applied t
Hi,
On Tue, Oct 26, 2021 at 2:56 PM Philip Chen wrote:
>
> Fit ps8640 driver into runtime power management framework:
>
> First, break _poweron() to 3 parts: (1) turn on power and wait for
> ps8640's internal MCU to finish init (2) check panel HPD (which is
> proxied by GPIO9) (3) the other confi
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the
actual compression algorithm is different from any previous platform; as
such, we ne
From: Stanislav Lisovskiy
TileF(Tile4 in bspec) format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Fixed wrong case condition(Jani Nikula)
- Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)
v3: - s/I915_TI
From: Anshuman Gupta
Handles the plane programing for flat ccs and clear color modifiers for
DG2
Signed-off-by: Anshuman Gupta
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthe
Details of the new features getting added as part of DG2 enabling and their
implicit impact on the uAPI.
v2: improvised the Flat-CCS documentation [Danvet & CQ]
Signed-off-by: Ramalingam C
cc: Daniel Vetter
cc: Matthew Auld
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Grau
Documents the Flat-CCS feature and kernel handling required along with
modifiers used.
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
drivers/gpu/drm/i915/gt/intel_
Remove the Y Tiling modifiers for DG2.
Signed-off-by: Ramalingam C
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_fb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 9ce1d
From: Ayaz A Siddiqui
Xe-hp and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated CCS buffer.
Flat CCS memory can not be directly accessed by S/W.
Ad
From: Abdiel Janulgue
A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”.
So to get effective device memory we need to subtract
total device memory by Flat CCS memory size.
From: CQ Tang
Gen12+ devices support 3D surface (buffer) compression and various
compression formats. This is accomplished by an additional compression
control state (CCS) stored for each surface.
Gen 12 devices(TGL family and DG1) stores compression states in a separate
region of memory. It is
From: Matthew Auld
The basic idea is that each 2M block(page-table) has a color, depending
on if the page-table is occupied by LMEM objects(64K) or SMEM
objects(4K), where our goal is to prevent mixing 64K and 4K GTT pages in
the page-table, which is not supported by the HW.
Signed-off-by: Matth
From: Matthew Auld
If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device local-memory pages for
this vm, since the
From: Matthew Auld
XEHPSDV optimises 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer sup
From: Matthew Auld
On some platforms the hw has dropped support for 4K GTT pages when
dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
can only mark the *entire* page-table as operating in 64K GTT mode,
since the enable bit is still on the pde, and not the pte. And since we
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Reviewed-by: Lucas De Ma
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c |
This series introduces the enabling patches for new memory compression
feature Flat CCS and 64k page support for i915 local memory, along with
documentation on the uAPI impact. Included the details of the feature and
the implications on the uAPI below. Which is also added into
Documentation/gpu/rfc
https://bugzilla.kernel.org/show_bug.cgi?id=214853
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 299339
--> https://bugzilla.kernel.org/attachment.cgi?id=299339&action=edit
kernel config (kernel 5.15-rc7, AMD FX-8370)
# lspci
00:00.0 Host bridge: Advanced Micro D
https://bugzilla.kernel.org/show_bug.cgi?id=214853
Bug ID: 214853
Summary: [amdgpu] UBSAN shows several null-ptr-deref in
../dc/bios/command_table2.c some
array-index-out-of-bounds in ../dc/bios/bios_parser2.c
and a
Sali Thomas
On Wed, 2021-10-27 at 20:30 +0200, Thomas Zimmermann wrote:
> Hi,
>
> thanks for the patch.
You are very welcome.
> Am 27.10.21 um 17:25 schrieb Marcel Ziswiler:
> > From: Marcel Ziswiler
> >
> > Today's -next fails building arm64 defconfig as follows:
> >
> > ERROR: modpost: mod
c: Matthew Auld
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c |1 +
1 file changed, 1 insertion(+)
--- linux-next-20211027.orig/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ linu
Hi Joonas,
On Wed, 27 Oct 2021 15:12:44 +0300 Joonas Lahtinen
wrote:
>
> We should be now good to go and add drm-intel-gt-next to linux-next.
>
> The branch would be as follows:
>
> drm-intel-gt-next git://anongit.freedesktop.org/drm-intel
> for-linux-next-gt
>
> Notice the "-gt" and the
On 10/27/21 22:34, John Harrison wrote:
On 10/26/2021 23:36, Thomas Hellström wrote:
Hi, John,
On 10/26/21 21:55, John Harrison wrote:
On 10/21/2021 23:23, Thomas Hellström wrote:
On 10/21/21 22:37, Matthew Brost wrote:
On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:
Hi,
https://bugzilla.kernel.org/show_bug.cgi?id=214847
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
# lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root
Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
00:01.0 Host bridge:
On 10/26/2021 23:36, Thomas Hellström wrote:
Hi, John,
On 10/26/21 21:55, John Harrison wrote:
On 10/21/2021 23:23, Thomas Hellström wrote:
On 10/21/21 22:37, Matthew Brost wrote:
On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:
Hi, Matthew,
On Mon, 2021-10-11 at 16:47 -070
Do a sanity check on pixclock value to avoid divide by zero.
If the pixclock value is zero, the cirrusfb driver will round up
pixclock to get the derived frequency as close to maxclock as
possible.
Syzkaller reported a divide error in cirrusfb_check_pixclock.
divide error: [#1] SMP KASAN PT
On Thu, 21 Oct 2021 11:27:01 +0200, Markus Schneider-Pargmann wrote:
> DP_INTF is similar to DPI but does not have the exact same feature set
> or register layouts.
>
> DP_INTF is the sink of the display pipeline that is connected to the
> DisplayPort controller and encoder unit. It takes the same
On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote:
> On 10/27/2021 12:17, Matthew Brost wrote:
> > On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote:
> > > On 10/20/2021 14:47, Matthew Brost wrote:
> > > > A weak implementation of parallel submission (multi-bb execbuf IOCTL)
On Mon, 25 Oct 2021 17:15:36 +0200, Maxime Ripard wrote:
> From: Rob Clark
>
> Switch to the documented order dsi-host vs bridge probe.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:35 +0200, Maxime Ripard wrote:
> Without proper care and an agreement between how DSI hosts and devices
> drivers register their MIPI-DSI entities and potential components, we can
> end up in a situation where the drivers can never probe.
>
> Most drivers were taking evas
On Mon, 25 Oct 2021 17:15:34 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:33 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:32 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:31 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:30 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:29 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge but don't remove its driver.
>
>
Applied to drm/drm-misc (drm-misc-next).
Than
On Mon, 25 Oct 2021 17:15:28 +0200, Maxime Ripard wrote:
> Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach
> callback") moved the unregistration of the bridge DSI device and bridge
> itself to the detach callback.
>
> While this is correct for the DSI device detach and unregistra
On Mon, 25 Oct 2021 17:15:27 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:26 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device on removal.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:25 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:24 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:23 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:22 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:21 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:20 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:19 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:18 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Mon, 25 Oct 2021 17:15:17 +0200, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thank
On Mon, 25 Oct 2021 17:15:16 +0200, Maxime Ripard wrote:
> Let's switch to the new devm MIPI-DSI function to register and attach
> our secondary device. This also avoids leaking the device when we detach
> the bridge.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, Oct 26, 2021 at 05:48:21PM -0700, Umesh Nerlige Ramappa wrote:
> With GuC handling scheduling, i915 is not aware of the time that a
> context is scheduled in and out of the engine. Since i915 pmu relies on
> this info to provide engine busyness to the user, GuC shares this info
> with i915
On 10/27/2021 12:17, Matthew Brost wrote:
On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote:
On 10/20/2021 14:47, Matthew Brost wrote:
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execl
On 2021-10-27 10:50 a.m., Christian König wrote:
Am 27.10.21 um 16:47 schrieb Andrey Grodzovsky:
On 2021-10-27 10:34 a.m., Christian König wrote:
Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky:
[SNIP]
Let me please know if I am still missing some point of yours.
Well, I mean we need to
27.10.2021 19:01, Ulf Hansson пишет:
> On Tue, 26 Oct 2021 at 00:45, 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 sh
27.10.2021 18:47, Ulf Hansson пишет:
>> Depending on hardware version, Tegra SoC may require a higher voltages
>> during resume from system suspend, otherwise hardware will crash. Set
>> SoC voltages to a nominal levels during suspend.
>>
>> Signed-off-by: Dmitry Osipenko
> I don't understand the
On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote:
> On 10/20/2021 14:47, Matthew Brost wrote:
> > A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
> > execlists. Doing as little as possible to support this interface for
> > execlists - basically just passing su
27.10.2021 18:06, Ulf Hansson пишет:
> On Tue, 26 Oct 2021 at 00:45, Dmitry Osipenko wrote:
>>
>> GENPD core now can set up domain's performance state properly while device
>> is RPM-suspended. Runtime PM of a device must be enabled during setup
>> because GENPD checks whether device is suspended
On 10/27/21 6:27 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
make any driver that needs it have a dependency on the class device
being available, to prevent circular dependencies.
This is the same way that the backli
On Tue, Oct 26, 2021 at 05:48:20PM -0700, Umesh Nerlige Ramappa wrote:
> In preparation for GuC pmu stats, add a name to the execlists stats
> structure so that it can be differentiated from the GuC stats.
>
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c
Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
replace it for the atomic PWM API.
Signed-off-by: Maíra Canal
Reported-by: kernel test robot
---
V1 -> V2: Initializing variable and simplyfing conditional loop
---
drivers/video/backlight/lp855x_bl.c | 23 +--
Hi Julian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.15-rc7 next-20211027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
umented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Julian-Braha/dt-bindings-panel-simple-dsi-add-Tianma-TL057FVXP01/20211022-053527
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: parisc-randconfig-s03
Hi,
On 10/27/21 15:38, Ville Syrjälä wrote:
> On Sun, Oct 24, 2021 at 05:50:10PM +0200, Hans de Goede wrote:
>> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
>> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>>
>> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for
On Mon, Oct 25, 2021 at 8:16 AM Maxime Ripard wrote:
>
> Without proper care and an agreement between how DSI hosts and devices
> drivers register their MIPI-DSI entities and potential components, we can
> end up in a situation where the drivers can never probe.
>
> Most drivers were taking evasiv
Hi,
thanks for the patch.
Am 27.10.21 um 17:25 schrieb Marcel Ziswiler:
From: Marcel Ziswiler
Today's -next fails building arm64 defconfig as follows:
ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from
namespace DMA_BUF, but does not import it.
ERROR: modpost: module drm
On 27/10/2021 11:52, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three
On Wed, Oct 27, 2021 at 05:23:59PM +0100, Matthew Auld wrote:
On Wed, 27 Oct 2021 at 15:54, Lucas De Marchi wrote:
On Wed, Oct 27, 2021 at 08:57:48AM +0100, Matthew Auld wrote:
>On Thu, 21 Oct 2021 at 13:54, Matthew Auld wrote:
>>
>> wbinvd_on_all_cpus() is only defined on x86 it seems, plus
On Wed, 2021-10-27 at 15:56 +0200, Patrice CHOTARD wrote:
> On 10/27/21 8:11 AM, Patrice CHOTARD wrote:
> > On 10/20/21 1:39 PM, Marc Zyngier wrote:
> > > On Wed, 20 Oct 2021 08:45:02 +0100,
> > > Krzysztof Kozlowski wrote:
> > > > On 20/10/2021 08:50, patrice.chot...@foss.st.com wrote:
> > > > >
1 - 100 of 207 matches
Mail list logo
