On Wed, 2 Nov 2022 22:34:04 +0200
Oded Gabbay wrote:
> +/**
> + * accel_open - open method for ACCEL file
> + * @inode: device inode
> + * @filp: file pointer.
> + *
> + * This function must be used by drivers as their _operations.open
> method.
> + * It looks up the correct ACCEL device and
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:49 PM
> > > ---
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +
> > > drivers/s390/cio/vfio_ccw_ops.c | 3 +
> > > drivers/s390/crypto/vfio_ap_ops.c | 3 +
> > > drivers/vfio/container.c | 108
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 7:51 PM
>
> On Tue, Nov 01, 2022 at 02:19:04AM -0700, Nicolin Chen wrote:
> > On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:
> >
> > > > From: Jason Gunthorpe
> > > > Sent: Wednesday, October 26, 2022 2:51 AM
> > > >
> > >
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:26 PM
> And this:
>
> /*
>* If the device does not have
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
>* any domain later attached to it will also not support it. If the cap
>* is set then the iommu_domain
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Change-Id: If0373f1e51273d2813ade3133b44638bc64a657c
---
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
Tested-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,ethdr.yaml | 188 ++
1 file changed, 188
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v27:
- rebase to next-20221102
- change mmsys compatible for mt8195 vdosys1
- base on jason's series[ref 1
This is a preparation for adding support for the ovl_adaptor sub driver
Ovl_adaptor is a DRM sub driver, which doesn't have dma dev. Add
dma_dev_get function for getting representative dma dev in ovl_adaptor.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioachino Del Regno
Reviewed-by: CK Hu
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Tested-by: Nícolas F. R. A. Prado
Add four mmsys config APIs. The config APIs are used for config
mmsys reg. Some mmsys regs need to be set according to the
HW engine binding to the mmsys simultaneously.
1. mtk_mmsys_merge_async_config: config merge async width/height.
async is used for cross-clock domain synchronization.
2.
Add mt8195 vdosys1 routing table to the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rex-BC Chen
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Change-Id: I11ce436a0921b4ab2ee86cc3737828fd56fc9cc0
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rex-BC Chen
Acked-by: Krzysztof Kozlowski
Acked-by: Philipp Zabel
Tested-by: AngeloGioacchino Del Regno
---
Add mmsys for support 64 reset bits. It is a preparation for MT8195
vdosys1 HW reset. MT8195 vdosys1 has more than 32 reset bits.
1. Add the number of reset bits in mmsys private data
2. move the whole "reset register code section" behind the
"get mmsys->data" code section for getting the
Simplify code for update mmsys reg.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Change-Id: I97f103153f08ada6f4e3582ad1fbe7f35e5190ba
---
drivers/soc/mediatek/mtk-mmsys.c | 45
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements
which include MDP_RDMA0~7, MERGE0~3, and ETHDR.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Add new mmsys component: ethdr_mixer and mdp_rdma. These components will
use in mt8195 vdosys1.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
---
include/linux/soc/mediatek/mtk-mmsys.h | 9
Add mtk-mutex DDP_COMPONENT_DP_INTF1 component. The MT8195 vdosys1 path
component contains ovl_adaptor, merge5, and dp_intf1. It is a preparation
for adding support for MT8195 vdosys1 path component.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Add the number of reset bits and reset base in mmsys
private data.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by:
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add mmsys and mutex modules support by the patches below:
Changes in v27:
- rebase to next-20221102
- change mmsys compatible for mt8195 vdosys1
- base on jason's series[ref 1
Add vdosys1 mmsys compatible for MT8195 platform.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Signed-off-by: Nancy.Lin
Change-Id: I8065205ce44baa417f58176adaae9e1eefa6eadb
---
Hi Dave, Daniel,
Fixes for 6.1. The big change here is the hang fix for the GC11 trap handler.
The following changes since commit 30a0b95b1335e12efef89dd78518ed3e4a71a763:
Linux 6.1-rc3 (2022-10-30 15:19:28 -0700)
are available in the Git repository at:
A problem about modprobe vc4 failed is triggered with the following log
given:
[ 420.327987] Error: Driver 'vc4_hvs' is already registered, aborting...
[ 420.333904] failed to register platform driver vc4_hvs_driver [vc4]: -16
modprobe: ERROR: could not insert 'vc4': Device or resource busy
A problem about modprobe mcde_drm failed is triggered with the following
log given:
[ 2387.922993] Error: Driver 'mcde-dsi' is already registered, aborting...
[ 2387.924272] failed to register platform driver mcde_dsi_driver [mcde_drm]:
-16
modprobe: ERROR: could not insert 'mcde_drm': Device
From: John Harrison
At the end of each test, IGT does a drop caches call via debugfs with
special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system times
On 11/2/2022 07:20, Tvrtko Ursulin wrote:
On 02/11/2022 12:12, Jani Nikula wrote:
On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
At the end of each test, IGT does a drop caches call via sysfs with
sysfs?
Sorry, that was meant to say debugfs. I've also been
On 11/2/2022 14:43, Daniele Ceraolo Spurio wrote:
On MTL there are no BCS engines on the media GT, so we can't always use
BCS0 in the test. There is no actual reason to use a BCS engine over an
engine of a different class, so switch to using any available engine.
Signed-off-by: Daniele Ceraolo
On Wed, Nov 02, 2022 at 10:34:03PM +0200, Oded Gabbay wrote:
> --- /dev/null
> +++ b/drivers/accel/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Compute Acceleration device configuration
> +#
> +# This framework provides support for compute acceleration devices,
On 26/10/2022 06:26, Bjorn Andersson wrote:
From: Bjorn Andersson
In the SC8280XP platform there are two identical MDSS instances, each
with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to
describe them both
On 26/10/2022 06:26, Bjorn Andersson wrote:
From: Bjorn Andersson
The Qualcomm SC8280XP platform contains DPU version 8.0.0, has 9
interfaces, 2 DSI controllers and 4 DisplayPort controllers. Extend the
necessary definitions and describe the DPU in the SC8280XP.
Signed-off-by: Bjorn Andersson
On 02/11/2022 01:33, Rob Clark wrote:
From: Rob Clark
If the hangcheck timer expires, check if the fw's position in the
cmdstream has advanced (changed) since last timer expiration, and
allow it up to three additional "extensions" to it's alotted time.
The intention is to continue to catch
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
Co-developed-by: Robert Foss
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
Add support for the MDSS block on SM8450 platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/qcom,sm8450-dpu.yaml | 132 +++
.../display/msm/qcom,sm8450-mdss.yaml | 349 ++
2 files changed, 481 insertions(+)
Add support for DSI 2.6.0 (block used on sm8450).
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git
SM8350 and SM8450 platforms use the same driver and same bindings as the
existing 7nm DSI PHYs. Add corresponding compatibility strings.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform.
Change since v1:
- Fixed the regdma pointer in sm8450_dpu_cfg
- Rebased onto pending msm-next-lumag
- Added DT bindings for corresponding devices
Dmitry Baryshkov (8):
dt-bindings: display/msm/dsi-controller-main: allow
Allow defining DSI OPP table inside the DSI controller node.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dsi-controller-main.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
On Wed, Nov 2, 2022 at 10:54 AM Dmitry Baryshkov
wrote:
>
> After the msm_iommu instance is created, the IOMMU domain is completely
> handled inside the msm_iommu code. Move the iommu_domain_alloc() call
> into the msm_iommu_new() to simplify callers code.
>
> Reported-by: kernel test robot
>
On Wed, Nov 2, 2022 at 10:54 AM Dmitry Baryshkov
wrote:
>
> The function a6xx_create_address_space() is mostly a copy of
> adreno_iommu_create_address_space() with added quirk setting. Rework
> these two functions to be a thin wrappers around a common helper.
>
> Signed-off-by: Dmitry Baryshkov
On 11/2/22 13:34, Oded Gabbay wrote:
> diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
> new file mode 100644
> index ..282ea24f90c5
> --- /dev/null
> +++ b/drivers/accel/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Compute Acceleration
Convert the mdp5.txt into the yaml format. Changes to the existing (txt) schema:
- MSM8996 has additional "iommu" clock, define it separately
- Add new properties used on some of platforms:
- interconnects, interconnect-names
- iommus
- power-domains
- operating-points-v2, opp-table
I had a massive disk crash, and my pull request is unsigned this one time.
However, it is signed with the promise the next tag will be signed again!
-
drm-misc-fixes-2022-11-02-1:
drm-misc-fixes for v6.1-rc4:
- Small fixes to make rockchip work better.
- Fix imx Kconfig.
- Small fix to imx'
On MTL there are no BCS engines on the media GT, so we can't always use
BCS0 in the test. There is no actual reason to use a BCS engine over an
engine of a different class, so switch to using any available engine.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
---
Starting on MTL, the GSC FW is loaded at runtime and will be managed
directly by i915. This means we now have a naming clash around the GSC,
as we have 2 different aspects of it that we need to handle: the HECI
interfaces we export pre-mtl and the new full FW loading and support we
have to
On 11/2/2022 2:34 PM, Oded Gabbay wrote:
@@ -163,7 +174,11 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
if (ret) {
- DRM_ERROR("DRM: Failed to initialize
On 11/2/2022 2:34 PM, Oded Gabbay wrote:
@@ -24,16 +33,6 @@ static char *accel_devnode(struct device *dev, umode_t *mode)
static CLASS_ATTR_STRING(accel_version, 0444, "accel 1.0.0 20221018");
-/**
- * accel_sysfs_init - initialize sysfs helpers
- *
- * This is used to create the ACCEL
On 11/2/2022 2:34 PM, Oded Gabbay wrote:
diff --git a/drivers/accel/accel_drv.c b/drivers/accel/accel_drv.c
new file mode 100644
index ..6132765ea054
--- /dev/null
+++ b/drivers/accel/accel_drv.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright 2022
Now that we have the accel framework code ready, let's call the
accel functions from all the appropriate places. These places are the
drm module init/exit functions, and all the drm_minor handling
functions.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/drm_drv.c | 98
The accelerator devices are exposed to user-space using a dedicated
major. In addition, they are represented in /dev with new, dedicated
device char names: /dev/accel/accel*. This is done to make sure any
user-space software that tries to open a graphic card won't open
the accelerator device by
Add a new Kconfig for the accel subsystem. The Kconfig currently
contains only the basic CONFIG_ACCEL option that will be used to
decide whether to compile the accel registration code. That code will
be called directly from the DRM core code.
The accelerator devices will be exposed to the user
This is the second version of the RFC following the comments given on the
first version. Nothing materially has changed in regard to how accel
devices are registered and exposed to user-space. The changes are mostly
re-factoring according to the comments.
Changes since v1:
- Instead of embedding
On 11/2/22 3:29 PM, Eric Farman wrote:
> On Wed, 2022-11-02 at 16:01 +0100, Eric Farman wrote:
>> Move the stuff associated with the mdev parent (and thus the
>> subchannel struct) into its own struct, and leave the rest in
>> the existing private structure.
>>
>> The subchannel will point to the
From: Rob Clark
Seems to be a leftover after commit e7cdf5c82f17 ("drm/syncobj: Stop
reusing the same struct file for all syncobj -> fd").
Signed-off-by: Rob Clark
---
include/drm/drm_syncobj.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/drm/drm_syncobj.h
Am Mittwoch, dem 02.11.2022 um 20:13 +0100 schrieb Christian König:
> Am 02.11.22 um 18:10 schrieb Lucas Stach:
> > Am Mittwoch, dem 02.11.2022 um 13:21 +0100 schrieb Christian König:
> > [SNIP]
> > > It would just be doing this for the importer and exactly that
> > > would be bad design because
On Wed, Nov 02, 2022 at 12:52:32PM +0100, Rasmus Villemoes wrote:
> On 24/10/2022 22.11, Gwan-gyeong Mun wrote:
> > From: Kees Cook
> >
> > Implement a robust overflows_type() macro to test if a variable or
> > constant value would overflow another variable or type. This can be
> > used as a
On Wed, 2022-11-02 at 16:01 +0100, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will point
> to the
On Wed, Nov 02, 2022 at 08:47:12AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to make sure the call target is valid to help mitigate
> ROP attacks. If
From: John Harrison
If a context has already been registered prior to first submission
then context init code was not being called. The noticeable effect of
that was the scheduling priority was left at zero (meaning super high
priority) instead of being set to normal. This would occur with
From: John Harrison
The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite
From: John Harrison
Fix for a deadlock issue between the GuC busyness stats worker and GT
resets. Also fix kernel contexts not getting the correct scheduling
priority at start of day.
v2: Rename existing uses of _trylock rather than adding a _noretry
version. Also improve the comment a bit.
Am 02.11.22 um 18:10 schrieb Lucas Stach:
Am Mittwoch, dem 02.11.2022 um 13:21 +0100 schrieb Christian König:
[SNIP]
It would just be doing this for the importer and exactly that
would be bad design because we then have handling for the display driver
outside of the driver.
The driver would
On Wed, Nov 02, 2022 at 08:56:23AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to make sure the call target is valid to help mitigate
> ROP attacks. If
On Wed, Nov 02, 2022 at 08:52:42AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to make sure the call target is valid to help mitigate
> ROP attacks. If
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 41 --
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Rename our internal helpers to remove the underscore prefix.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 --
1 file changed, 2 deletions(-)
The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 4
Introduce two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.
This allows DRM drivers to rely on drm_kms_helper_poll for
Merge drm_kms_helper_poll_disable() and drm_kms_helper_poll_fini() code
into a common helper function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_probe_helper.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git
Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver
>From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_connector's HPD, make that automatic.
Add two
On 02/11/2022 20:28, Doug Anderson wrote:
Hi,
On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov
wrote:
1. Someone figures out how to model this with the bridge chain and
then we only allow HBR3 if we detect we've got a TCPC that supports
it. This seems like the cleanest / best but feels like
The function a6xx_create_address_space() is mostly a copy of
adreno_iommu_create_address_space() with added quirk setting. Rework
these two functions to be a thin wrappers around a common helper.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
After the msm_iommu instance is created, the IOMMU domain is completely
handled inside the msm_iommu code. Move the iommu_domain_alloc() call
into the msm_iommu_new() to simplify callers code.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
Simplify the MSM IOMMU code a bit. This moves iommu_domain_alloc() and
iommu_set_pgtable_quirks() calls to msm_iommu_new() to get rid of the
disbalance, when the iommu domain is allocated by the caller of
msm_iommu_new() and then it is freed by the msm_iommu code itself.
Changes since v3:
-
On 02/11/2022 20:25, Doug Anderson wrote:
Hi,
On Wed, Nov 2, 2022 at 10:15 AM Dmitry Baryshkov
wrote:
On 01/11/2022 17:37, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM
Reviewed-by: Tony Krowiak : vfio_ap part
On 11/2/22 11:01 AM, Eric Farman wrote:
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release
On Tue, 01 Nov 2022 17:17:59 +0100, Luca Weiss wrote:
> Document the compatible for the wled block found in PMI8950.
>
> Signed-off-by: Luca Weiss
> ---
> Changes since v2:
> * New patch
>
> Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 +
> 1 file changed, 1
Hi,
On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov
wrote:
>
> > 1. Someone figures out how to model this with the bridge chain and
> > then we only allow HBR3 if we detect we've got a TCPC that supports
> > it. This seems like the cleanest / best but feels like a long pole.
> > Not only have
Hi,
On Wed, Nov 2, 2022 at 10:15 AM Dmitry Baryshkov
wrote:
>
> On 01/11/2022 17:37, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 01/11/2022 03:08, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Oct 31, 2022 at 2:11 PM Kuogee
On 02/11/2022 18:47, Doug Anderson wrote:
Hi,
On Tue, Nov 1, 2022 at 7:37 AM Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM Kuogee Hsieh wrote:
Hi Dmitry,
Link rate is
On 11/2/22 10:58 AM, Dawei Li wrote:
Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create
On 01/11/2022 17:37, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 5:15 PM Dmitry Baryshkov
wrote:
On 01/11/2022 03:08, Doug Anderson wrote:
Hi,
On Mon, Oct 31, 2022 at 2:11 PM Kuogee Hsieh wrote:
Hi Dmitry,
Link rate is advertised by sink, but adjusted (reduced the link rate)
by
Am Mittwoch, dem 02.11.2022 um 13:21 +0100 schrieb Christian König:
> Hi Lucas,
>
> Am 02.11.22 um 12:39 schrieb Lucas Stach:
> > Hi Christian,
> >
> > going to reply in more detail when I have some more time, so just some
> > quick thoughts for now.
> >
> > Am Mittwoch, dem 02.11.2022 um 12:18
Starting on MTL, the GSC is no longer managed with direct MMIO access,
but we instead have a dedicated command streamer for it. As a first step
for adding support for this CS, add the required definitions.
Note that, although it is now a CS, the GSC retains its old
class:instance value
Starting on MTL, the GSC microcontroller resides inside the media GT
and the driver can communicate with it via a new Command Streamer, the
GSC CS. As a first step in supporting the GSC integration within the
media GT, this series adds the required defines and basic support for
this CS. Note that,
We need to tell the GuC that the GSC CS is there.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 11 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 7 +--
2 files changed, 10 insertions(+), 8
There is no userspace user for this CS yet, we only need it for internal
kernel ops (e.g. HuC, PXP), so don't expose it.
v2: even if it's not exposed, rename the engine so it is easier to
identify in the debug logs (Matt)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
---
The GSC CS has its own dedicated bit in the GDRST register.
Bspec: 52549
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
2 files changed, 2 insertions(+)
diff
The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.
v2: clean up the if statement for the engine irq (Tvrtko)
Signed-off-by: Daniele Ceraolo Spurio
On 01/11/2022 13:59, Kalyan Thota wrote:
This patch does the following:
1) Registers crtc color management to the first crtc in the list and
attach to an encoder which is neither pluggable nor virtual
2) Pin 1 crtc to 1 encoder
3) Assign dspp block if crtc supports color processing.
A clear
On Wed, Nov 2, 2022 at 8:59 AM Dawei Li wrote:
>
> Racing conflict could be:
> task A task B
> list_for_each_entry
> strcmp(h->name))
>list_for_each_entry
>strcmp(h->name)
> kzallockzalloc
> ..
1 - 100 of 173 matches
Mail list logo
