[PATCH] dma-buf: fix dma_buf_export init order v2
The init order and resulting error handling in dma_buf_export
was pretty messy.
Subordinate objects like the file and the sysfs kernel objects
were initializing and wiring itself up with the object in the
wrong order resulting not only in complicating and partially
incorrect error handling, but also in publishing only halve
initialized DMA-buf objects.
Clean this up thoughtfully by allocating the file independent
of the DMA-buf object. Then allocate and initialize the DMA-buf
object itself, before publishing it through sysfs. If everything
works as expected the file is then connected with the DMA-buf
object and publish it through debugfs.
Also adds the missing dma_resv_fini() into the error handling.
v2: add some missing changes to dma_bug_getfile() and a missing NULL
check in dma_buf_file_release()
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf-sysfs-stats.c | 7 +--
drivers/dma-buf/dma-buf-sysfs-stats.h | 4 +-
drivers/dma-buf/dma-buf.c | 84 +--
3 files changed, 43 insertions(+), 52 deletions(-)
diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c
b/drivers/dma-buf/dma-buf-sysfs-stats.c
index 2bba0babcb62..4b680e10c15a 100644
--- a/drivers/dma-buf/dma-buf-sysfs-stats.c
+++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
@@ -168,14 +168,11 @@ void dma_buf_uninit_sysfs_statistics(void)
kset_unregister(dma_buf_stats_kset);
}
-int dma_buf_stats_setup(struct dma_buf *dmabuf)
+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file)
{
struct dma_buf_sysfs_entry *sysfs_entry;
int ret;
- if (!dmabuf || !dmabuf->file)
- return -EINVAL;
-
if (!dmabuf->exp_name) {
pr_err("exporter name must not be empty if stats needed\n");
return -EINVAL;
@@ -192,7 +189,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf)
/* create the directory for buffer stats */
ret = kobject_init_and_add(_entry->kobj, _buf_ktype, NULL,
- "%lu", file_inode(dmabuf->file)->i_ino);
+ "%lu", file_inode(file)->i_ino);
if (ret)
goto err_sysfs_dmabuf;
diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h
b/drivers/dma-buf/dma-buf-sysfs-stats.h
index a49c6e2650cc..7a8a995b75ba 100644
--- a/drivers/dma-buf/dma-buf-sysfs-stats.h
+++ b/drivers/dma-buf/dma-buf-sysfs-stats.h
@@ -13,7 +13,7 @@
int dma_buf_init_sysfs_statistics(void);
void dma_buf_uninit_sysfs_statistics(void);
-int dma_buf_stats_setup(struct dma_buf *dmabuf);
+int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file);
void dma_buf_stats_teardown(struct dma_buf *dmabuf);
#else
@@ -25,7 +25,7 @@ static inline int dma_buf_init_sysfs_statistics(void)
static inline void dma_buf_uninit_sysfs_statistics(void) {}
-static inline int dma_buf_stats_setup(struct dma_buf *dmabuf)
+static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file
*file)
{
return 0;
}
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e6f36c014c4c..eb6b59363c4f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -95,10 +95,11 @@ static int dma_buf_file_release(struct inode *inode, struct
file *file)
return -EINVAL;
dmabuf = file->private_data;
-
- mutex_lock(_list.lock);
- list_del(>list_node);
- mutex_unlock(_list.lock);
+ if (dmabuf) {
+ mutex_lock(_list.lock);
+ list_del(>list_node);
+ mutex_unlock(_list.lock);
+ }
return 0;
}
@@ -523,17 +524,17 @@ static inline int is_dma_buf_file(struct file *file)
return file->f_op == _buf_fops;
}
-static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
+static struct file *dma_buf_getfile(size_t size, int flags)
{
static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
- struct file *file;
struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
+ struct file *file;
if (IS_ERR(inode))
return ERR_CAST(inode);
- inode->i_size = dmabuf->size;
- inode_set_bytes(inode, dmabuf->size);
+ inode->i_size = size;
+ inode_set_bytes(inode, size);
/*
* The ->i_ino acquired from get_next_ino() is not unique thus
@@ -547,8 +548,6 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
flags, _buf_fops);
if (IS_ERR(file))
goto err_alloc_file;
- file->private_data = dmabuf;
- file->f_path.dentry->d_fsdata = dmabuf;
return file;
@@ -614,19 +613,11 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
size_t alloc_size = sizeof(struct dma_buf);
int ret;
- if (!exp_info->resv)
- alloc_size += sizeof(struct dma_resv);
- else
- /* prevent _buf[1] ==
[PATCH] drm/bridge: anx7625: keep last configure timing
Sometimes kernel may resume back quickly after suspend,
and DRM not call .mode_set() to re-config
display timing before calling .atomic_enable(), bridge
driver with this patch to keep last configure timing.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b0ff1ecb80a5..eb9116503b63 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1403,7 +1403,6 @@ static void anx7625_stop_dp_work(struct anx7625_data *ctx)
{
ctx->hpd_status = 0;
ctx->hpd_high_cnt = 0;
- ctx->display_timing_valid = 0;
}
static void anx7625_start_dp_work(struct anx7625_data *ctx)
--
2.25.1
Re: [PATCH v5 00/12] drm/msm: Add SC8280XP support
On Wed, Dec 7, 2022 at 4:00 PM Bjorn Andersson wrote: > > This introduces support for the SC8280XP platform in the MDSS, DPU and > DP driver. It reworks the HDP handling in the DP driver to support > external HPD sources - such as the dp-connector, or USB Type-C altmode. > > It then introduces the display clock controllers, mdss, dpu and > displayport controllers and link everything together, for both the MDSS > instances on the platform, and lastly enables EDP on the compute > reference device and 6 of the MiniDP outputs on the automotive > development platform. > > > The patches was previously sent separately, but submitting them together > here as they (except dts addition) goes in the same tree. > > Bjorn Andersson (12): > dt-bindings: display/msm: Add binding for SC8280XP MDSS > drm/msm/dpu: Introduce SC8280XP > drm/msm: Introduce SC8280XP MDSS > dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles > drm/msm/dp: Stop using DP id as index in desc > drm/msm/dp: Add DP and EDP compatibles for SC8280XP > drm/msm/dp: Add SDM845 DisplayPort instance > drm/msm/dp: Rely on hpd_enable/disable callbacks > drm/msm/dp: Implement hpd_notify() > arm64: dts: qcom: sc8280xp: Define some of the display blocks > arm64: dts: qcom: sc8280xp-crd: Enable EDP > arm64: dts: qcom: sa8295-adp: Enable DP instances > > .../bindings/display/msm/dp-controller.yaml | 3 + > .../display/msm/qcom,sc8280xp-dpu.yaml| 122 +++ > .../display/msm/qcom,sc8280xp-mdss.yaml | 143 +++ > arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 243 - > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 72 +- > arch/arm64/boot/dts/qcom/sc8280xp.dtsi| 838 ++ > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 217 + > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 + > .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 + > .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 + > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 + > drivers/gpu/drm/msm/dp/dp_display.c | 151 ++-- > drivers/gpu/drm/msm/dp/dp_display.h | 1 + > drivers/gpu/drm/msm/dp/dp_drm.c | 3 + > drivers/gpu/drm/msm/dp/dp_drm.h | 4 + > drivers/gpu/drm/msm/msm_drv.h | 1 + > drivers/gpu/drm/msm/msm_mdss.c| 4 + > 18 files changed, 1770 insertions(+), 57 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml > > -- > 2.37.3 > Tested on Lenovo Thinkpad X13s Tested-by: Steev Klimaszewski
Re: [git pull] drm fixes for 6.1 final
The pull request you sent on Fri, 9 Dec 2022 10:51:00 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-12-09 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0d1409e4ff08aa4a9a254d3f723410db32aa7552 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[git pull] drm fixes for 6.1 final
Hi Linus, Last set of fixes for final, scattered bunch of fixes, two amdgpu, one vmwgfx, and some misc others. Dave. drm-fixes-2022-12-09: drm fixes for 6.1-rc9 amdgpu: - S0ix fix - DCN 3.2 array out of bounds fix shmem: - Fixes to shmem-helper error paths. bridge: - Fix polarity bug in bridge/ti-sn65dsi86. dw-hdmi: - Prefer 8-bit RGB fallback before any YUV mode in dw-hdmi, since some panels lie about YUV support. vmwgfx: - Stop using screen objects when SEV is active. The following changes since commit 76dcd734eca23168cb008912c0f69ff408905235: Linux 6.1-rc8 (2022-12-04 14:48:12 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-12-09 for you to fetch changes up to c4252650a8c4770b669398fe7270ed8c94fc0eba: Merge tag 'drm-misc-fixes-2022-12-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-12-09 10:11:06 +1000) drm fixes for 6.1-rc9 amdgpu: - S0ix fix - DCN 3.2 array out of bounds fix shmem: - Fixes to shmem-helper error paths. bridge: - Fix polarity bug in bridge/ti-sn65dsi86. dw-hdmi: - Prefer 8-bit RGB fallback before any YUV mode in dw-hdmi, since some panels lie about YUV support. vmwgfx: - Stop using screen objects when SEV is active. Aurabindo Pillai (1): drm/amd/display: fix array index out of bound error in DCN32 DML Dave Airlie (2): Merge tag 'amd-drm-fixes-6.1-2022-12-07' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2022-12-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Dawei Li (1): drm/vmwgfx: Fix race issue calling pin_user_pages Guillaume BRUN (1): drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420 Prike Liang (1): drm/amdgpu/sdma_v4_0: turn off SDMA ring buffer in the s2idle suspend Qiqi Zhang (1): drm/bridge: ti-sn65dsi86: Fix output polarity setting bug Rob Clark (2): drm/shmem-helper: Remove errant put in error path drm/shmem-helper: Avoid vm_open error paths Zack Rusin (1): drm/vmwgfx: Don't use screen objects when SEV is active drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 24 ++ .../gpu/drm/amd/display/dc/dml/display_mode_vba.h | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +++--- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++-- drivers/gpu/drm/drm_gem_shmem_helper.c | 18 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 6 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 7 files changed, 40 insertions(+), 24 deletions(-)
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 09/12/2022 02:22, Kuogee Hsieh wrote:
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the example
validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml" at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that either
of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected
failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object',
'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
"make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
msm-next and reports a single example-related warning in
msm-next-lumag. I pushed a patch to fix that warning (wich can
hopefully be picked up by Abhinav into msm-fixes). So you can assume
that both these branches have consistent error-free display/msm schemas.
I have clean msm-next branch (without my data-lines yaml patch applied)
and run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml", then I saw below error messages.
Have you run into this problem?
No.
HOSTCC scripts/basic/fixdep
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
This means that somewhere in your path you have an older dtschema instance.
When you sent me a question regarding this error, I asked for the
additional info. You provided none. Instead you went on sending the
untested patch that doesn't work.
But I did not check trainiling whitespace this time.
---
.../bindings/display/msm/dp-controller.yaml | 27
++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ remote-endpoint: true
PLease add empty lines between the property definitions
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 3
enum: [0, 1, 2, 3]
+
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the example
validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that either
of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected
failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object',
'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
"make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
msm-next and reports a single example-related warning in
msm-next-lumag. I pushed a patch to fix that warning (wich can
hopefully be picked up by Abhinav into msm-fixes). So you can assume
that both these branches have consistent error-free display/msm schemas.
I have clean msm-next branch (without my data-lines yaml patch applied)
and run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
then I saw below error messages.
Have you run into this problem?
HOSTCC scripts/basic/fixdep
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
But I did not check trainiling whitespace this time.
---
.../bindings/display/msm/dp-controller.yaml | 27
++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ remote-endpoint: true
PLease add empty lines between the property definitions
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 3
enum: [0, 1, 2, 3]
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 81
I think we can have enum here too.
+
+ required:
+ - port@0
+ - port@1
+
required:
-
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the example
validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml" at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that either
of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object', 'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
"make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
msm-next and reports a single example-related warning in msm-next-lumag.
I pushed a patch to fix that warning (wich can hopefully be picked up by
Abhinav into msm-fixes). So you can assume that both these branches have
consistent error-free display/msm schemas.
But I did not check trainiling whitespace this time.
---
.../bindings/display/msm/dp-controller.yaml | 27
++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ remote-endpoint: true
PLease add empty lines between the property definitions
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 3
enum: [0, 1, 2, 3]
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 81
I think we can have enum here too.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -193,6 +218,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <162000
27 54 81>;
};
};
};
--
With best wishes
Dmitry
Re: [PATCH] dt-bindings: msm/dsi: Don't require vcca-supply on 14nm PHY
On Wed, 30 Nov 2022 at 15:58, Konrad Dybcio wrote: > > On some SoCs (hello SM6115) vcca-supply is not wired to any smd-rpm > or rpmh regulator, but instead powered by the VDD_MX line, which is > voted for in the DSI ctrl node. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the example
validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
at mu v5.15 branch since
"make dt_binding_check" does not work at msm-next branch.
But I did not check trainiling whitespace this time.
---
.../bindings/display/msm/dp-controller.yaml | 27
++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ remote-endpoint: true
PLease add empty lines between the property definitions
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 3
enum: [0, 1, 2, 3]
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 81
I think we can have enum here too.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -193,6 +218,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <162000
27 54 81>;
};
};
};
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And after
fixing the error in the schema I faced an example validation error. Did
you check that the schema is correct and that the example validates
against the schema?
---
.../bindings/display/msm/dp-controller.yaml| 27 ++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+
+properties:
+ remote-endpoint: true
PLease add empty lines between the property definitions
+ data-lanes:
+$ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
+minItems: 1
+maxItems: 4
+items:
+ maximum: 3
enum: [0, 1, 2, 3]
+ link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+minItems: 1
+maxItems: 4
+items:
+ maximum: 81
I think we can have enum here too.
+
+ required:
+- port@0
+- port@1
+
required:
- compatible
- reg
@@ -193,6 +218,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+data-lanes = <0 1>;
+link-frequencies = /bits/ 64 <162000 27
54 81>;
};
};
};
--
With best wishes
Dmitry
Re: [PATCH v5 03/12] drm/msm: Introduce SC8280XP MDSS
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
Add compatible for the SC8280XP Mobile Display Subsystem and
initialization for version 8.0.0.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- None
drivers/gpu/drm/msm/msm_mdss.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 86b28add1fff..8677e74868cf 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -287,6 +287,9 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
case DPU_HW_VER_720:
msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_3_0, 6, 1, 1, 1);
break;
+ case DPU_HW_VER_800:
+ msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_4_0, 6, 1, 2, 1);
+ break;
}
return ret;
@@ -513,6 +516,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sc7180-mdss" },
{ .compatible = "qcom,sc7280-mdss" },
{ .compatible = "qcom,sc8180x-mdss" },
+ { .compatible = "qcom,sc8280xp-mdss" },
{ .compatible = "qcom,sm6115-mdss" },
{ .compatible = "qcom,sm8150-mdss" },
{ .compatible = "qcom,sm8250-mdss" },
Re: [PATCH v5 02/12] drm/msm/dpu: Introduce SC8280XP
On 12/7/2022 2:00 PM, 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
Signed-off-by: Bjorn Andersson
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- Fix highest_bank_bit, based on downstream
- Add ubwc_swizzle
- Use CTL_SC7280_MASK instead of listing the bits directly
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 217 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
7 files changed, 243 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 2196e205efa5..0315fe68af2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -124,6 +124,19 @@
BIT(MDP_AD4_0_INTR) | \
BIT(MDP_AD4_1_INTR))
+#define IRQ_SC8280XP_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+ BIT(MDP_SSPP_TOP0_INTR2) | \
+ BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+ BIT(MDP_INTF0_7xxx_INTR) | \
+ BIT(MDP_INTF1_7xxx_INTR) | \
+ BIT(MDP_INTF2_7xxx_INTR) | \
+ BIT(MDP_INTF3_7xxx_INTR) | \
+ BIT(MDP_INTF4_7xxx_INTR) | \
+ BIT(MDP_INTF5_7xxx_INTR) | \
+ BIT(MDP_INTF6_7xxx_INTR) | \
+ BIT(MDP_INTF7_7xxx_INTR) | \
+ BIT(MDP_INTF8_7xxx_INTR))
+
#define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
BIT(DPU_WB_UBWC) | \
BIT(DPU_WB_YUV_CONFIG) | \
@@ -365,6 +378,20 @@ static const struct dpu_caps sc8180x_dpu_caps = {
.max_vdeci_exp = MAX_VERT_DECIMATION,
};
+static const struct dpu_caps sc8280xp_dpu_caps = {
+ .max_mixer_width = 2560,
+ .max_mixer_blendstages = 11,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3LITE,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_caps sm8250_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
@@ -545,6 +572,25 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sc8280xp_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = 0,
+ .highest_bank_bit = 2,
+ .ubwc_swizzle = 6,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = { .reg_off = 0x2ac, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = { .reg_off = 0x2b4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = { .reg_off = 0x2bc, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = { .reg_off = 0x2c4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = { .reg_off = 0x2bc, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = { .reg_off = 0x2c4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20},
+ },
+};
+
static const struct dpu_mdp_cfg qcm2290_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -648,6 +694,45 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sc8280xp_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x204,
+ .features = CTL_SC7280_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ },
+ {
+ .name = "ctl_4", .id =
Re: [PATCH v11 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
-- separate parser link-frequencies out of data-lanes
Changes in v10:
-- add dp_parser_link_frequencies()
Changes in v11:
-- return 0 if(!endpoint)
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 27 +++
drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..9a7dcd4 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -91,6 +91,29 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
return 0;
}
+static u32 dp_parser_link_frequencies(struct device_node *of_node)
+{
+ struct device_node *endpoint;
+ u64 frequency = 0;
+ int cnt = 0;
+
+ endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
+ if (!endpoint)
+ return 0;
+
+ cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+
+ if (cnt > 0)
+ of_property_read_u64_index(endpoint, "link-frequencies",
+ cnt - 1, );
+ of_node_put(endpoint);
+
+ frequency /= 10;/* from symbol rate to link rate */
+ frequency /= 1000; /* kbytes */
+
+ return frequency;
+}
+
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
@@ -113,6 +136,10 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes
*/
}
+ parser->max_dp_link_rate = dp_parser_link_frequencies(of_node);
+ if (!parser->max_dp_link_rate)
+parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
Drop the comment please. One can jump to the defined value to see what
is it equal to. So it adds no information.
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..6b10c3e 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
#define DP_LABEL "MDSS DP DISPLAY"
#define DP_MAX_PIXEL_CLK_KHZ 675000
#define DP_MAX_NUM_DP_LANES 4
+#define DP_LINK_RATE_HBR2 54 /* khz */
kbytes, not kHz. Otherwise it would have been 540.
enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
int (*parse)(struct dp_parser *parser);
--
With best wishes
Dmitry
Re: [PATCH v5 09/12] drm/msm/dp: Implement hpd_notify()
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal on a GPIO pin into the controller. This is not always
possible, either because there aren't dedicated GPIOs available or
because the hot-plug signal is a virtual notification, in cases such as
USB Type-C.
For these cases, by implementing the hpd_notify() callback for the
DisplayPort controller's drm_bridge, a downstream drm_bridge
(next_bridge) can be used to track and signal the connection status
changes.
This makes it possible to use downstream drm_bridges such as
display-connector or any virtual mechanism, as long as they are
implemented as a drm_bridge.
Signed-off-by: Bjorn Andersson
[bjorn: Drop connector->fwnode assignment and dev from struct msm_dp]
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- Look at internal_hpd now that it's introduced before this patch.
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
drivers/gpu/drm/msm/dp/dp_drm.c | 1 +
drivers/gpu/drm/msm/dp/dp_drm.h | 2 ++
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 095adf528e43..0bee412603fe 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1792,3 +1792,25 @@ void dp_bridge_hpd_disable(struct drm_bridge *bridge)
dp_display->internal_hpd = false;
}
+
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
+ struct msm_dp *dp_display = dp_bridge->dp_display;
+ struct dp_display_private *dp = container_of(dp_display, struct
dp_display_private, dp_display);
+
+ /* Without next_bridge interrupts are handled by the DP core directly */
+ if (dp_display->internal_hpd)
+ return;
+
+ if (!dp->core_initialized) {
+ drm_dbg_dp(dp->drm_dev, "not initialized\n");
+ return;
+ }
+
+ if (!dp_display->is_connected && status == connector_status_connected)
+ dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
+ else if (dp_display->is_connected && status ==
connector_status_disconnected)
+ dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
+}
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 9d03b6ee3c41..275370f21115 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -104,6 +104,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
.atomic_check = dp_bridge_atomic_check,
.hpd_enable = dp_bridge_hpd_enable,
.hpd_disable = dp_bridge_hpd_disable,
+ .hpd_notify = dp_bridge_hpd_notify,
};
struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index 1f871b555006..250f7c66201f 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -34,5 +34,7 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
const struct drm_display_mode *adjusted_mode);
void dp_bridge_hpd_enable(struct drm_bridge *bridge);
void dp_bridge_hpd_disable(struct drm_bridge *bridge);
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status);
#endif /* _DP_DRM_H_ */
Re: [PATCH v5 04/12] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
On 08/12/2022 00:00, Bjorn Andersson wrote: From: Bjorn Andersson Add compatibles for the DisplayPort and Embedded DisplayPort blocks in Qualcomm SDM845 and SC8280XP platforms. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Acked-by: Krzysztof Kozlowski --- Changes since v4: - None .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index f2515af8256f..a1dc3a13e1cf 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -21,6 +21,9 @@ properties: - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp + - qcom,sc8280xp-dp + - qcom,sc8280xp-edp This also should be added to the eDP conditional, to allow the aux-bus child node (and disallow #sound-dai-cells). + - qcom,sdm845-dp - qcom,sm8350-dp reg: -- With best wishes Dmitry
Re: [PATCH v5 08/12] drm/msm/dp: Rely on hpd_enable/disable callbacks
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The DisplayPort controller's internal HPD interrupt handling is used for
cases where the HPD signal is connected to a GPIO which is pinmuxed into
the DisplayPort controller. In other configurations the HPD notification
might be delivered by the DRM framework from an associated bridge.
This difference is not appropriately represented by the "is_edp"
boolean, but is properly represented by the frameworks invocation of the
hpd_enable() and hpd_disable() callbacks. Switch the current condition
to rely on these callbacks instead.
This ensures appropriate handling of the three cases; no bridge
connected, a bridge without DRM_BRIDGE_OP_HPD and a bridge with
DRM_BRIDGE_OP_HPD.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- Reordered the hpd_enable/disable patch earlier
- Squashed in internal_hpd conditional changes into the same patch
drivers/gpu/drm/msm/dp/dp_display.c | 40 +
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dp/dp_drm.c | 2 ++
drivers/gpu/drm/msm/dp/dp_drm.h | 2 ++
4 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 666b45c8ab80..095adf528e43 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
}
/* enable HDP irq_hpd/replug interrupt */
- dp_catalog_hpd_config_intr(dp->catalog,
- DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true);
+ if (dp->dp_display.internal_hpd)
+ dp_catalog_hpd_config_intr(dp->catalog,
+ DP_DP_IRQ_HPD_INT_MASK |
DP_DP_HPD_REPLUG_INT_MASK,
+ true);
drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
dp->dp_display.connector_type, state);
@@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
dp->dp_display.connector_type, state);
/* disable irq_hpd/replug interrupts */
- dp_catalog_hpd_config_intr(dp->catalog,
- DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false);
+ if (dp->dp_display.internal_hpd)
+ dp_catalog_hpd_config_intr(dp->catalog,
+ DP_DP_IRQ_HPD_INT_MASK |
DP_DP_HPD_REPLUG_INT_MASK,
+ false);
/* unplugged, no more irq_hpd handle */
dp_del_event(dp, EV_IRQ_HPD_INT);
@@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
}
/* disable HPD plug interrupts */
- dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false);
+ if (dp->dp_display.internal_hpd)
+ dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK, false);
/*
* We don't need separate work for disconnect as
@@ -696,7 +701,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
dp_display_handle_plugged_change(>dp_display, false);
/* enable HDP plug interrupt to prepare for next plugin */
- if (!dp->dp_display.is_edp)
+ if (dp->dp_display.internal_hpd)
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK, true);
drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n",
@@ -1081,8 +1086,8 @@ static void dp_display_config_hpd(struct
dp_display_private *dp)
dp_display_host_init(dp);
dp_catalog_ctrl_hpd_config(dp->catalog);
- /* Enable plug and unplug interrupts only for external DisplayPort */
- if (!dp->dp_display.is_edp)
+ /* Enable plug and unplug interrupts only if requested */
+ if (dp->dp_display.internal_hpd)
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK |
DP_DP_HPD_UNPLUG_INT_MASK,
@@ -1374,8 +1379,7 @@ static int dp_pm_resume(struct device *dev)
dp_catalog_ctrl_hpd_config(dp->catalog);
-
- if (!dp->dp_display.is_edp)
+ if (dp->dp_display.internal_hpd)
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_HPD_PLUG_INT_MASK |
DP_DP_HPD_UNPLUG_INT_MASK,
@@ -1772,3 +1776,19 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
dp_display->dp_mode.h_active_low =
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
}
+
+void dp_bridge_hpd_enable(struct drm_bridge *bridge)
+{
+ struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
+ struct msm_dp *dp_display = dp_bridge->dp_display;
+
+
Re: [PATCH v5 07/12] drm/msm/dp: Add SDM845 DisplayPort instance
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The Qualcomm SDM845 platform has a single DisplayPort controller, with
the same design as SC7180, so add support for this by reusing the SC7180
definition.
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5b7f1f885b2f..666b45c8ab80 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -178,6 +178,7 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
+ { .compatible = "qcom,sdm845-dp", .data = _dp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
Re: [PATCH v5 06/12] drm/msm/dp: Add DP and EDP compatibles for SC8280XP
On 12/7/2022 2:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The SC8280XP platform has four DisplayPort controllers, per MDSS
instance, all with widebus support.
The first two are defined to be DisplayPort only, while the latter pair
(of each instance) can be either DisplayPort or Embedded DisplayPort.
The two sets are tied to the possible compatibels.
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index eeb292f1ad1b..5b7f1f885b2f 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -145,6 +145,26 @@ static const struct msm_dp_desc sc8180x_dp_descs[] = {
{}
};
+static const struct msm_dp_desc sc8280xp_dp_descs[] = {
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ {}
+};
+
+static const struct msm_dp_desc sc8280xp_edp_descs[] = {
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
+};
+
static const struct msm_dp_desc sm8350_dp_descs[] = {
{ .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
{}
@@ -156,6 +176,8 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc7280-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
Re: [PATCH v5 05/12] drm/msm/dp: Stop using DP id as index in desc
On 12/7/2022 2:00 PM, 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 in the same table and hence have a single compatible.
While at it, flatten the cfg/desc structure so that the match data is
just an array of descs.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Reviewed-by: Kuogee Hsieh
---
Changes since v4:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 72 ++---
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7ff60e5ff325..eeb292f1ad1b 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -122,61 +122,41 @@ struct dp_display_private {
struct msm_dp_desc {
phys_addr_t io_start;
+ unsigned int id;
unsigned int connector_type;
bool wide_bus_en;
};
-struct msm_dp_config {
- const struct msm_dp_desc *descs;
- size_t num_descs;
-};
-
static const struct msm_dp_desc sc7180_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sc7180_dp_cfg = {
- .descs = sc7180_dp_descs,
- .num_descs = ARRAY_SIZE(sc7180_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct msm_dp_desc sc7280_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0aea, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
-};
-
-static const struct msm_dp_config sc7280_dp_cfg = {
- .descs = sc7280_dp_descs,
- .num_descs = ARRAY_SIZE(sc7280_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
};
static const struct msm_dp_desc sc8180x_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0ae98000, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_2] = { .io_start = 0x0ae9a000, .connector_type =
DRM_MODE_CONNECTOR_eDP },
-};
-
-static const struct msm_dp_config sc8180x_dp_cfg = {
- .descs = sc8180x_dp_descs,
- .num_descs = ARRAY_SIZE(sc8180x_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP },
+ {}
};
static const struct msm_dp_desc sm8350_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sm8350_dp_cfg = {
- .descs = sm8350_dp_descs,
- .num_descs = ARRAY_SIZE(sm8350_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct of_device_id dp_dt_match[] = {
- { .compatible = "qcom,sc7180-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-edp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-edp", .data = _dp_cfg },
- { .compatible = "qcom,sm8350-dp", .data = _dp_cfg },
+ { .compatible = "qcom,sc7180-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
@@ -1262,10 +1242,9 @@ int dp_display_request_irq(struct msm_dp *dp_display)
return 0;
}
-static const struct msm_dp_desc *dp_display_get_desc(struct platform_device *pdev,
-unsigned int *id)
+static const struct msm_dp_desc *dp_display_get_desc(struct platform_device
*pdev)
{
- const struct msm_dp_config *cfg = of_device_get_match_data(>dev);
[PATCH v11 5/5] drm/msm/dp: add support of max dp link rate
By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary pr_err
Changes in v5:
-- split parser function into different patch
Changes in v9:
-- revised commit test
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 4
drivers/gpu/drm/msm/dp/dp_panel.c | 7 ---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
struct edid *edid;
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+ dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+ drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+ dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
+ /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
- /* Limit support upto HBR2 until HBR3 support is added */
- if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
- link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+ /* Limit link rate from link-frequencies of endpoint properity of dtsi
*/
+ if (link_info->rate > dp_panel->max_dp_link_rate)
+ link_info->rate = dp_panel->max_dp_link_rate;
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
u32 vic;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
u32 max_bw_code;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
---
.../bindings/display/msm/dp-controller.yaml| 27 ++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+
+properties:
+ remote-endpoint: true
+ data-lanes:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+maxItems: 4
+items:
+ maximum: 3
+ link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+minItems: 1
+maxItems: 4
+items:
+ maximum: 81
+
+ required:
+- port@0
+- port@1
+
required:
- compatible
- reg
@@ -193,6 +218,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <>;
+data-lanes = <0 1>;
+link-frequencies = /bits/ 64 <162000 27
54 81>;
};
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v11 3/5] drm/msm/dp: parser data-lanes as property of dp_out endpoint
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_parser.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..b5f7e70 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,16 +94,25 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
- int len;
-
- len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
- if (len < 0) {
- DRM_WARN("Invalid property \"data-lanes\", default max DP lanes
= %d\n",
-DP_MAX_NUM_DP_LANES);
- len = DP_MAX_NUM_DP_LANES;
+ int cnt;
+
+ /*
+* data-lanes is the property of dp_out endpoint
+*/
+ cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1,
DP_MAX_NUM_DP_LANES);
+ if (cnt > 0)
+ parser->max_dp_lanes = cnt;
+ else {
+ /*
+* legacy code, data-lanes is the property of mdss_dp node
+*/
+ cnt = drm_of_get_data_lanes_count(of_node, 1,
DP_MAX_NUM_DP_LANES);
+ if (cnt > 0)
+ parser->max_dp_lanes = cnt;
+ else
+ parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes
*/
}
- parser->max_dp_lanes = len;
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v11 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
-- separate parser link-frequencies out of data-lanes
Changes in v10:
-- add dp_parser_link_frequencies()
Changes in v11:
-- return 0 if(!endpoint)
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 27 +++
drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..9a7dcd4 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -91,6 +91,29 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
return 0;
}
+static u32 dp_parser_link_frequencies(struct device_node *of_node)
+{
+ struct device_node *endpoint;
+ u64 frequency = 0;
+ int cnt = 0;
+
+ endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
+ if (!endpoint)
+ return 0;
+
+ cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+
+ if (cnt > 0)
+ of_property_read_u64_index(endpoint, "link-frequencies",
+ cnt - 1, );
+ of_node_put(endpoint);
+
+ frequency /= 10;/* from symbol rate to link rate */
+ frequency /= 1000; /* kbytes */
+
+ return frequency;
+}
+
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
@@ -113,6 +136,10 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes
*/
}
+ parser->max_dp_link_rate = dp_parser_link_frequencies(of_node);
+ if (!parser->max_dp_link_rate)
+parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 54 khz */
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..6b10c3e 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
#define DP_LABEL "MDSS DP DISPLAY"
#define DP_MAX_PIXEL_CLK_KHZ 675000
#define DP_MAX_NUM_DP_LANES4
+#define DP_LINK_RATE_HBR2 54 /* khz */
enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
int (*parse)(struct dp_parser *parser);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v11 1/5] arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add _out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Changes in v7:
-- change 16000 to 162000
-- separate yaml to different patch
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v9:
-- use symbol rate (hz) for link-frequencies at dp_out at sc7180_trogdor.dtsi
Signed-off-by: Kuogee Hsieh
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..93b0cde 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+data-lanes = <0 1>;
+link-frequencies = /bits/ 64 <162000 27 54>;
};
_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index c11e371..3c7a9d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -442,7 +442,11 @@ ap_i2c_tpm: {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <162000 27 54
81>;
};
_mdp {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v11 0/5] Add data-lanes and link-frequencies to dp_out endpoint
Add DP both data-lanes and link-frequencies property to dp_out endpoint and support functions to DP driver. Kuogee Hsieh (5): arm64: dts: qcom: add data-lanes and link-freuencies into dp_out endpoint dt-bindings: msm/dp: add data-lanes and link-frequencies property drm/msm/dp: parser data-lanes as property of dp_out endpoint drm/msm/dp: parser link-frequencies as property of dp_out endpoint drm/msm/dp: add support of max dp link rate .../bindings/display/msm/dp-controller.yaml| 27 +++ arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 ++- arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 ++- drivers/gpu/drm/msm/dp/dp_display.c| 4 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 7 +-- drivers/gpu/drm/msm/dp/dp_panel.h | 1 + drivers/gpu/drm/msm/dp/dp_parser.c | 52 ++ drivers/gpu/drm/msm/dp/dp_parser.h | 2 + 8 files changed, 92 insertions(+), 13 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v7 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support
On Thu, Dec 08, 2022 at 08:54:39PM +0530, Akhil P Oommen wrote:
> On 12/7/2022 9:16 PM, Ulf Hansson wrote:
> > On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen
> > wrote:
> >> Allow a consumer driver to poll for cx gdsc collapse through Reset
> >> framework.
> > Would you mind extending this commit message, to allow us to better
> > understand what part is really the consumer part.
> Sure. I can do that.
> >
> > I was expecting the consumer part to be the GPU (adreno) driver, but I
> > may have failed to understand correctly. It would be nice to see an
> > example of a typical sequence, where the reset is being
> > asserted/deasserted, from the consumer point of view. Would you mind
> > explaining this a bit more?
> https://elixir.bootlin.com/linux/v6.1-rc8/source/drivers/gpu/drm/msm/adreno/a6xx_gpu.c#L1309
> You are correct. The consumer is adreno gpu driver. When there is a gpu
> fault, these sequences are followed:
> 1. drop pm_runtime_put() for gpu device which will drops its vote on 'cx'
> genpd. line: 1306
> 2. At this point, there could be vote from either smmu driver (smmu is under
> same power domain too) or from other subsystems (tz/hyp).
Can you confirm that this is happening completely independent of what
the kernel does?
> 3. So we call into gdsc driver through reset interface to poll the gdsc
> register to ensure it collapsed at least once. Line: 1309
I other words, if we engineered 1. such that it would wait in
gdsc_disable() until the condition for 3. is reached, that should work
for you? (Obviously depending on the ability for us to engineer this...)
Regards,
Bjorn
> 4. Then we turn ON gpu. line:1314.
>
> -Akhil.
> >
> >> Signed-off-by: Akhil P Oommen
> >> Reviewed-by: Dmitry Baryshkov
> > Kind regards
> > Uffe
> >
> >> ---
> >>
> >> (no changes since v3)
> >>
> >> Changes in v3:
> >> - Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const'
> >> (Krzysztof)
> >>
> >> Changes in v2:
> >> - Minor update to use the updated custom reset ops implementation
> >>
> >> drivers/clk/qcom/gpucc-sc7280.c | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/drivers/clk/qcom/gpucc-sc7280.c
> >> b/drivers/clk/qcom/gpucc-sc7280.c
> >> index 9a832f2..fece3f4 100644
> >> --- a/drivers/clk/qcom/gpucc-sc7280.c
> >> +++ b/drivers/clk/qcom/gpucc-sc7280.c
> >> @@ -433,12 +433,22 @@ static const struct regmap_config
> >> gpu_cc_sc7280_regmap_config = {
> >> .fast_io = true,
> >> };
> >>
> >> +static const struct qcom_reset_ops cx_gdsc_reset = {
> >> + .reset = gdsc_wait_for_collapse,
> >> +};
> >> +
> >> +static const struct qcom_reset_map gpucc_sc7280_resets[] = {
> >> + [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
> >> +};
> >> +
> >> static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
> >> .config = _cc_sc7280_regmap_config,
> >> .clks = gpu_cc_sc7280_clocks,
> >> .num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
> >> .gdscs = gpu_cc_sc7180_gdscs,
> >> .num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
> >> + .resets = gpucc_sc7280_resets,
> >> + .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
> >> };
> >>
> >> static const struct of_device_id gpu_cc_sc7280_match_table[] = {
> >> --
> >> 2.7.4
> >>
>
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote: > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote: > > > > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote: > > > On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote: > > > > > > > > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > > > > > > > > > > > > > @Ulf, Akhil has a power-domain for a piece of hardware which may be > > > > voted active by multiple different subsystems (co-processors/execution > > > > contexts) in the system. > > > > > > > > As such, during the powering down sequence we don't wait for the > > > > power-domain to turn off. But in the event of an error, the recovery > > > > mechanism relies on waiting for the hardware to settle in a powered off > > > > state. > > > > > > > > The proposal here is to use the reset framework to wait for this state > > > > to be reached, before continuing with the recovery mechanism in the > > > > client driver. > > > > > > I tried to review the series (see my other replies), but I am not sure > > > I fully understand the consumer part. > > > > > > More exactly, when and who is going to pull the reset and at what point? > > > > > > > > > > > Given our other discussions on quirky behavior, do you have any > > > > input/suggestions on this? > > > > > > > > > Some clients like adreno gpu driver would like to ensure that its gdsc > > > > > is collapsed at hardware during a gpu reset sequence. This is because > > > > > it > > > > > has a votable gdsc which could be ON due to a vote from another > > > > > subsystem > > > > > like tz, hyp etc or due to an internal hardware signal. To allow > > > > > this, gpucc driver can expose an interface to the client driver using > > > > > reset framework. Using this the client driver can trigger a polling > > > > > within > > > > > the gdsc driver. > > > > > > > > @Akhil, this description is fairly generic. As we've reached the state > > > > where the hardware has settled and we return to the client, what > > > > prevents it from being powered up again? > > > > > > > > Or is it simply a question of it hitting the powered-off state, not > > > > necessarily staying there? > > > > > > Okay, so it's indeed the GPU driver that is going to assert/de-assert > > > the reset at some point. Right? > > > > > > That seems like a reasonable approach to me, even if it's a bit > > > unclear under what conditions that could happen. > > > > > > > Generally the disable-path of the power-domain does not check that the > > power-domain is actually turned off, because the status might indicate > > that the hardware is voting for the power-domain to be on. > > Is there a good reason why the HW needs to vote too, when the GPU > driver is already in control? > > Or perhaps that depends on the running use case? > > > > > As part of the recovery of the GPU after some fatal fault, the GPU > > driver does something which will cause the hardware votes for the > > power-domain to be let go, and then the driver does pm_runtime_put(). > > Okay. That "something", sounds like a device specific setting for the > corresponding gdsc, right? > > So somehow the GPU driver needs to manage that setting, right? > > > > > But in this case the GPU driver wants to ensure that the power-domain is > > actually powered down, before it does pm_runtime_get() again. To ensure > > that the hardware lost its state... > > I see. > > > > > The proposal here is to use a reset to reach into the power-domain > > provider and wait for the hardware to be turned off, before the GPU > > driver attempts turning the power-domain on again. > > > > > > In other words, there is no reset. This is a hack to make a normally > > asynchronous pd.power_off() to be synchronous in this particular case. > > Alright, assuming I understood your clarifications above correctly > (thanks!), I think I have got a much better picture now. > > Rather than abusing the reset interface, I think we should manage this > through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU > driver should register its corresponding device for them > (dev_pm_genpd_add_notifier()). > > The trick however, is to make the behaviour of the power-domain for > the gdsc (the genpd->power_off() callback) conditional on whether the > HW is configured to vote or not. If the HW can vote, it should not > poll for the state - and vice versa when the HW can't vote. > Per Akhil's description I misunderstood who the other voters are; but either way it's not the same "HW configured" mechanism as the one we're already discussing. But if we based on similar means could control if the power_off() ops should be blocking, waiting for the status indication to show that the hardware is indeed powered down, I think this would meet the needs. And GENPD_NOTIFY_OFF seems to provide the notification that it was successful (i.e. happened within the timeout etc). > Would this work? > If we can control the behavior of the genpd, I
Re: [PATCH v1] drm/bridge: lt8912b: Add hot plug detection
On Mon, 28 Nov 2022 12:23:20 +0100, Francesco Dolcini wrote: > From: Stefan Eichenberger > > Enable hot plug detection when it is available on the HDMI port. > Without this connecting to a different monitor with incompatible timing > before the 10 seconds poll period will lead to a broken display output. > > > [...] Applied, thanks! Repo: https://cgit.freedesktop.org/drm/drm-misc/ [1/1] drm/bridge: lt8912b: Add hot plug detection commit: 3b0a01a6a5224ed9b3f69f44edaa889b2e2b9779 rob
Re: [PATCH v12 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
On 12/8/2022 10:05 AM, Alan Previn wrote: Starting with MTL, there will be two GT-tiles, a render and media tile. PXP as a service for supporting workloads with protected contexts and protected buffers can be subscribed by process workloads on any tile. However, depending on the platform, only one of the tiles is used for control events pertaining to PXP operation (such as creating the arbitration session and session tear-down). PXP as a global feature is accessible via batch buffer instructions on any engine/tile and the coherency across tiles is handled implicitly by the HW. In fact, for the foreseeable future, we are expecting this single-control-tile for the PXP subsystem. In MTL, it's the standalone media tile (not the root tile) because it contains the VDBOX and KCR engine (among the assets PXP relies on for those events). Looking at the current code design, each tile is represented by the intel_gt structure while the intel_pxp structure currently hangs off the intel_gt structure. Keeping the intel_pxp structure within the intel_gt structure makes some internal functionalities more straight forward but adds code complexity to code readability and maintainibility to many external-to-pxp subsystems which may need to pick the correct intel_gt structure. An example of this would be the intel_pxp_is_active or intel_pxp_is_enabled functionality which should be viewed as a global level inquiry, not a per-gt inquiry. That said, this series promotes the intel_pxp structure into the drm_i915_private structure making it a top-level subsystem and the PXP subsystem will select the control gt internally and keep a pointer to it for internal reference. This promotion comes with two noteworthy changes: 1. Exported pxp functions that are called by external subsystems (such as intel_pxp_enabled/active) will have to check implicitly if i915->pxp is valid as that structure will not be allocated for HW that doesn't support PXP. 2. Since GT is now considered a soft-dependency of PXP we are ensuring that GT init happens before PXP init and vice versa for fini. This causes a minor ordering change whereby we previously called intel_pxp_suspend after intel_uc_suspend but now is before i915_gem_suspend_late but the change is required for correct dependency flows. Additionally, this re-order change doesn't have any impact because at that point in either case, the top level entry to i915 won't observe any PXP events (since the GPU was quiesced during suspend_prepare). Also, any PXP event doesn't really matter when we disable the PXP HW (global GT irqs are already off anyway, so even if there was a bug that generated spurious events we wouldn't see it and we would just clean it up on resume which is okay since the default fallback action for PXP would be to keep the sessions off at this suspend stage). Changes from prior revs: v11: - Reformat a comment (Tvrtko). v10: - Change the code flow for intel_pxp_init to make it more cleaner and readible with better comments explaining the difference between full-PXP-feature vs the partial-teelink inits depending on the platform. Additionally, only do the pxp allocation when we are certain the subsystem is needed. (Tvrtko). v9: - Cosmetic cleanups in supported/enabled/active. (Daniele). - Add comments for intel_pxp_init and pxp_get_ctrl_gt that explain the functional flow for when PXP is not supported but the backend-assets are needed for HuC authentication (Daniele and Tvrtko). - Fix two remaining functions that are accessible outside PXP that need to be checking pxp ptrs before using them: intel_pxp_irq_handler and intel_pxp_huc_load_and_auth (Tvrtko and Daniele). - User helper macro in pxp-debugfs (Tvrtko). v8: - Remove pxp_to_gt macro (Daniele). - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't support GSC-FW on it. (Daniele). - Leave i915->pxp as NULL if we dont support PXP and in line with that, do additional validity check on i915->pxp for intel_pxp_is_supported/enabled/active (Daniele). - Remove unncessary include header from intel_gt_debugfs.c and check drm_minor i915->drm.primary (Daniele). - Other cosmetics / minor issues / more comments on suspend flow order change (Daniele). v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp' through out instead of local variable newpxp. (Rodrigo) - In the case intel_pxp_fini is called during driver unload but after i915 loading failed without pxp being allocated, check i915->pxp before referencing it. (Alan) v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported because : [1] introduction of 'ctrl_gt' means we correct this for MTL's
Re: [PATCH] drm/display: Include missing DPCD definitions from DP2.0 spec
+ dri-devel On Thu, Dec 8, 2022 at 2:25 PM Sung Joon Kim wrote: > > The missing DPCD defintions from DP2.0 spec is as follows: > > DOWNSPREAD_CTRL (107h): > ADAPTIVE_SYNC_SDP_EN (bit 6) > For sink devices that support Adaptive-Sync operation > and Panel Replay > > DPRX_FEATURE_ENUMERATION_LIST_CONT_1 (2214h): > ADAPTIVE_SYNC_SDP_SUPPORTED (bit 0) > Bit to check sink device has Adaptive-Sync capability > AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED (bit > 1) > A sink device that clears this bit will generate VSync pulse > leading edge of the HDMI output on the line count at which > Adaptive-Sync SDP is received as long as source device > transmits > Adaptive-Sync SDP either in first line or first 3840 pixel > cycles > of the line whichever occurs first. > VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED (bit 4) > Bit to check sink device has SDP framework version 1 > capability > --- > include/drm/display/drm_dp.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 4d0abe4c7ea9..4f33b6aeb91e 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -603,6 +603,7 @@ > > #define DP_DOWNSPREAD_CTRL 0x107 > # define DP_SPREAD_AMP_0_5 (1 << 4) > +# define DP_ADAPTIVE_SYNC_SDP_EN(1 << 6) > # define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) /* eDP */ > > #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 > @@ -1105,6 +1106,11 @@ > # define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */ > # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */ > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1 0x2214 /* 2.0 E11 */ > +# define DP_ADAPTIVE_SYNC_SDP_SUPPORTED(1 << 0) > +# define DP_AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED > (1 << 1) > +# define DP_VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED (1 << 4) > + > #define DP_128B132B_SUPPORTED_LINK_RATES 0x2215 /* 2.0 */ > # define DP_UHBR10 (1 << 0) > # define DP_UHBR20 (1 << 1) > -- > 2.20.1 >
[PULL] drm-misc-fixes
Hey Dave, drm-misc-fixes for v6.1 final. A bit late, hopefully just in time. drm-misc-fixes-2022-12-08: drm-misc-fixes for v6.1 final?: - Fix polarity bug in bridge/ti-sn65dsi86. - Prefer 8-bit RGB fallback before any YUV mode in dw-hdmi, since some panels lie about YUV support. - Fixes to shmem-helper error paths. - Small vmwgfx to stop using screen objects when SEV is active. The following changes since commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f: fbcon: Use kzalloc() in fbcon_prepare_logo() (2022-11-22 15:48:02 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-12-08 for you to fetch changes up to 6e90293618ed476d6b11f82ce724efbb9e9a071b: drm/vmwgfx: Don't use screen objects when SEV is active (2022-12-05 13:59:38 -0500) drm-misc-fixes for v6.1 final?: - Fix polarity bug in bridge/ti-sn65dsi86. - Prefer 8-bit RGB fallback before any YUV mode in dw-hdmi, since some panels lie about YUV support. - Fixes to shmem-helper error paths. - Small vmwgfx to stop using screen objects when SEV is active. Dawei Li (1): drm/vmwgfx: Fix race issue calling pin_user_pages Guillaume BRUN (1): drm: bridge: dw_hdmi: fix preference of RGB modes over YUV420 Qiqi Zhang (1): drm/bridge: ti-sn65dsi86: Fix output polarity setting bug Rob Clark (2): drm/shmem-helper: Remove errant put in error path drm/shmem-helper: Avoid vm_open error paths Zack Rusin (1): drm/vmwgfx: Don't use screen objects when SEV is active drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +++--- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++-- drivers/gpu/drm/drm_gem_shmem_helper.c| 18 -- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 5 files changed, 24 insertions(+), 14 deletions(-)
Re: [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function
On Wed, Nov 23, 2022 at 12:05:51PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
>
> v2: Removed multiple blank lines
> v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp
> to reflect its meaning more properly.
> (Manasi Navare)
>
> Signed-off-by: Stanislav Lisovskiy
Looks good now,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 50 +
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 -
> 3 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 44e2424a54c0..d78216fba0a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -672,6 +672,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
> return 6144 * 8;
> }
>
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp)
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(>drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> @@ -680,7 +710,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>
> /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -713,24 +742,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel,
> pipe_bpp);
>
> /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..e4faccf87370 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> }
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp);
>
> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 59f80af8d17d..b4f01c01dc1c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -115,7
[PATCH v12 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
Starting with MTL, there will be two GT-tiles, a render and media tile. PXP as a service for supporting workloads with protected contexts and protected buffers can be subscribed by process workloads on any tile. However, depending on the platform, only one of the tiles is used for control events pertaining to PXP operation (such as creating the arbitration session and session tear-down). PXP as a global feature is accessible via batch buffer instructions on any engine/tile and the coherency across tiles is handled implicitly by the HW. In fact, for the foreseeable future, we are expecting this single-control-tile for the PXP subsystem. In MTL, it's the standalone media tile (not the root tile) because it contains the VDBOX and KCR engine (among the assets PXP relies on for those events). Looking at the current code design, each tile is represented by the intel_gt structure while the intel_pxp structure currently hangs off the intel_gt structure. Keeping the intel_pxp structure within the intel_gt structure makes some internal functionalities more straight forward but adds code complexity to code readability and maintainibility to many external-to-pxp subsystems which may need to pick the correct intel_gt structure. An example of this would be the intel_pxp_is_active or intel_pxp_is_enabled functionality which should be viewed as a global level inquiry, not a per-gt inquiry. That said, this series promotes the intel_pxp structure into the drm_i915_private structure making it a top-level subsystem and the PXP subsystem will select the control gt internally and keep a pointer to it for internal reference. This promotion comes with two noteworthy changes: 1. Exported pxp functions that are called by external subsystems (such as intel_pxp_enabled/active) will have to check implicitly if i915->pxp is valid as that structure will not be allocated for HW that doesn't support PXP. 2. Since GT is now considered a soft-dependency of PXP we are ensuring that GT init happens before PXP init and vice versa for fini. This causes a minor ordering change whereby we previously called intel_pxp_suspend after intel_uc_suspend but now is before i915_gem_suspend_late but the change is required for correct dependency flows. Additionally, this re-order change doesn't have any impact because at that point in either case, the top level entry to i915 won't observe any PXP events (since the GPU was quiesced during suspend_prepare). Also, any PXP event doesn't really matter when we disable the PXP HW (global GT irqs are already off anyway, so even if there was a bug that generated spurious events we wouldn't see it and we would just clean it up on resume which is okay since the default fallback action for PXP would be to keep the sessions off at this suspend stage). Changes from prior revs: v11: - Reformat a comment (Tvrtko). v10: - Change the code flow for intel_pxp_init to make it more cleaner and readible with better comments explaining the difference between full-PXP-feature vs the partial-teelink inits depending on the platform. Additionally, only do the pxp allocation when we are certain the subsystem is needed. (Tvrtko). v9: - Cosmetic cleanups in supported/enabled/active. (Daniele). - Add comments for intel_pxp_init and pxp_get_ctrl_gt that explain the functional flow for when PXP is not supported but the backend-assets are needed for HuC authentication (Daniele and Tvrtko). - Fix two remaining functions that are accessible outside PXP that need to be checking pxp ptrs before using them: intel_pxp_irq_handler and intel_pxp_huc_load_and_auth (Tvrtko and Daniele). - User helper macro in pxp-debugfs (Tvrtko). v8: - Remove pxp_to_gt macro (Daniele). - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't support GSC-FW on it. (Daniele). - Leave i915->pxp as NULL if we dont support PXP and in line with that, do additional validity check on i915->pxp for intel_pxp_is_supported/enabled/active (Daniele). - Remove unncessary include header from intel_gt_debugfs.c and check drm_minor i915->drm.primary (Daniele). - Other cosmetics / minor issues / more comments on suspend flow order change (Daniele). v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp' through out instead of local variable newpxp. (Rodrigo) - In the case intel_pxp_fini is called during driver unload but after i915 loading failed without pxp being allocated, check i915->pxp before referencing it. (Alan) v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported because : [1] introduction of 'ctrl_gt' means we correct this for MTL's upcoming series now. [2] Also, this has little impact globally as its only used by
Re: [PATCH] drm/amdgpu: Retry DDC probing on DVI on failure if we got an HPD interrupt
On Wed, Dec 7, 2022 at 3:09 AM xurui wrote:
>
> HPD signals on DVI ports can be fired off before the pins required for
> DDC probing actually make contact, due to the pins for HPD making
> contact first. This results in a HPD signal being asserted but DDC
> probing failing, resulting in hotplugging occasionally failing.
It seems like DP should get a similar fix.
>
> Rescheduling the hotplug work for a second when we run into an HPD
> signal with a failing DDC probe usually gives enough time for the rest
> of the connector's pins to make contact, and fixes this issue.
This looks reasonable. Please address the kernel test robot reports.
Thanks,
Alex
>
> Signed-off-by: xurui
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 22 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index cfb262911bfc..dd8d414249a5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -997,13 +997,33 @@ amdgpu_connector_dvi_detect(struct drm_connector
> *connector, bool force)
> }
> }
>
> + if (amdgpu_connector->detected_hpd_without_ddc) {
> + force = true;
> + amdgpu_connector->detected_hpd_without_ddc = false;
> + }
> +
> if (!force && amdgpu_connector_check_hpd_status_unchanged(connector))
> {
> ret = connector->status;
> goto exit;
> }
>
> - if (amdgpu_connector->ddc_bus)
> + if (amdgpu_connector->ddc_bus) {
> dret = amdgpu_display_ddc_probe(amdgpu_connector, false);
> +
> + /* Sometimes the pins required for the DDC probe on DVI
> +* connectors don't make contact at the same time that the
> ones
> +* for HPD do. If the DDC probe fails even though we had an
> HPD
> +* signal, try again later
> +*/
> + if (!dret && !force &&
> + amdgpu_display_hpd_sense(adev,
> amdgpu_connector->hpd.hpd)) {
> + DRM_DEBUG_KMS("hpd detected without ddc, retrying in
> 1 second\n");
> + amdgpu_connector->detected_hpd_without_ddc = true;
> + schedule_delayed_work(>hotplug_work,
> + msecs_to_jiffies(1000));
> + goto exit;
> + }
> + }
> if (dret) {
> amdgpu_connector->detected_by_load = false;
> amdgpu_connector_free_edid(connector);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 37322550d750..bf009de59710 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -535,6 +535,7 @@ struct amdgpu_connector {
> void *con_priv;
> bool dac_load_detect;
> bool detected_by_load; /* if the connection status was determined by
> load */
> + bool detected_hpd_without_ddc; /* if an HPD signal was detected on
> DVI, but ddc probing failed */
> uint16_t connector_object_id;
> struct amdgpu_hpd hpd;
> struct amdgpu_router router;
> --
> 2.25.1
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
Re: [Intel-gfx] [PATCH v11 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
On Thu, 2022-12-08 at 09:29 +, Tvrtko Ursulin wrote: > Just some small comments and questions below. > > On 08/12/2022 05:01, Alan Previn wrote: > > Starting with MTL, there will be two GT-tiles, a render and media > > Alan:[snip] > IMO this looks great now - pretty self-documenting, all the complicated > checks are contained to the init phase, and the comments are really good. > > Hopefully someone who knows the flows can cross-check this approach and > r-b, Daniele I suspect (copied)? From me its an ack. > > Acked-by: Tvrtko Ursulin > Alan: Thanks Tvrtko. As per offline email, i created an internal JIRA to track the other follow ups (intel_pxp_foo(pxp) -> intel_pxp_foo(i915) and inlines that could use CONFIG_I915_PXP - something that was there before but was removed for DG2 - perhaps could be added back in with accommodation on the internal functions). I will rev v12 to fix the comments and Daniele has agreed to review the changes from v9 (prior RB point).
Re: [PATCH 019/606] drm/bridge: chrontel-ch7033: Convert to i2c's .probe_new()
On Wed, 7 Dec 2022 at 15:15, Uwe Kleine-König wrote: > > Hello dear drm/bridge maintainers, > > On Fri, Nov 18, 2022 at 11:35:53PM +0100, Uwe Kleine-König wrote: > > From: Uwe Kleine-König > > > > The probe function doesn't make use of the i2c_device_id * parameter so it > > can be trivially converted. > > > > Signed-off-by: Uwe Kleine-König > > Do you plan to pick up the drm/bridge patches in the upcoming cycle? > > You could do that using: > > git pull > https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git > i2c/client_device_id_helper-immutable > b4 am -l -3 -P 14-35,37 20221118224540.619276-20-...@kleine-koenig.org > git am -s ./20221118_uwe_i2c_complete_conversion_to_i2c_probe_new.mbx > > Note that Doug Anderson already applied the patch for ti-sn65dsi86, > which is patch #36 and so this is skipped in the above range. Applied to drm-misc-next. Feel free to grab a hold of me out of band if you hit any snags like this again.
Re: [PATCH linux-next v2 00/10] drm: Remove some obsolete drivers(tdfx, mga, i810, savage, r128, sis, via)
On Sat, 3 Dec 2022 at 09:45, Cai Huoqing wrote:
>
> Commit 399516ab0fee ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers")
> marked these drivers obsolete 7 years ago.
As the author of said patch - calling them obsolete was a bad decision
on my part.
They are effectively orphan with no maintainer and no other driver(s)
that provide the same, or equivalent functionality.
As a DRM newcomer I would recommend sticking to smaller and more
tangible tasks. The TODO list has plenty of varying complexity.
[1] https://www.kernel.org/doc/html/latest/gpu/todo.html
Re: [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use
On Thu, Dec 08, 2022 at 02:14:54PM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 08, 2022 at 02:54:45PM +0200, Andy Shevchenko wrote: > > On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote: > > > Some of the existing users, and definitely will be new ones, want to > > > count existing nodes in the list. Provide a generic API for that by > > > moving code from i915 to list.h. > > > > Greg, I believe this one is ready to be taken. Or please tell me what I need > > to do. > > Wait for me to get through the current backlog of patches that I have in > my review queue. Odds are, it will have to wait until after 6.2-rc1 is > out based on when 6.1 is going to be released. It's fine, no hurry and take your time! > Don't worry, it's not lost. Thank you, got it! -- With Best Regards, Andy Shevchenko
Re: [PATCH] drm/amd/display: Fix spelling mistake: "dram_clk_chanage" -> "dram_clk_change"
On 12/8/22 07:18, Colin Ian King wrote:
There is a spelling mistake in the struct field dram_clk_chanage. Fix it.
Signed-off-by: Colin Ian King
Applied. Thanks!
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
.../drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h | 2 +-
7 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
index 0f746bb4e500..d51f1ce02874 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
@@ -55,7 +55,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_A);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_A);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_A);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_A);
s = >sets[1];
s->wm_set = 1;
@@ -65,7 +65,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_B);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_B);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_B);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_B);
s = >sets[2];
s->wm_set = 2;
@@ -75,7 +75,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_C);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_C);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_C);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_C);
s = >sets[3];
s->wm_set = 3;
@@ -85,7 +85,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_D);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_D);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_D);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_D);
}
void hubbub1_allow_self_refresh_control(struct hubbub *hubbub, bool allow)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index c8ec11839b4d..fe2023f18b7d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -159,7 +159,7 @@ static void dcn10_log_hubbub_state(struct dc *dc,
DTN_INFO_MICRO_SEC(s->pte_meta_urgent);
DTN_INFO_MICRO_SEC(s->sr_enter);
DTN_INFO_MICRO_SEC(s->sr_exit);
- DTN_INFO_MICRO_SEC(s->dram_clk_chanage);
+ DTN_INFO_MICRO_SEC(s->dram_clk_change);
DTN_INFO("\n");
}
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
index e8b6065fffad..a0f8e31d2adc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
@@ -83,7 +83,7 @@ static unsigned int dcn10_get_hubbub_state(struct dc *dc,
char *pBuf, unsigned i
memset(, 0, sizeof(struct dcn_hubbub_wm));
dc->res_pool->hubbub->funcs->wm_read_state(dc->res_pool->hubbub, );
- chars_printed = snprintf_count(pBuf, remaining_buffer, "wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n");
+ chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_change\n");
remaining_buffer -= chars_printed;
pBuf += chars_printed;
@@ -98,7 +98,7 @@ static unsigned int dcn10_get_hubbub_state(struct dc *dc, char *pBuf, unsigned i
(s->pte_meta_urgent * frac) / ref_clk_mhz / frac,
(s->pte_meta_urgent * frac) / ref_clk_mhz % frac,
(s->sr_enter * frac) / ref_clk_mhz / frac, (s->sr_enter
* frac) / ref_clk_mhz % frac,
(s->sr_exit * frac) / ref_clk_mhz / frac, (s->sr_exit *
frac) / ref_clk_mhz % frac,
- (s->dram_clk_chanage * frac) / ref_clk_mhz / frac,
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On 12/7/2022 9:30 PM, Ulf Hansson wrote: > On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote: >> On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: >> @Ulf, Akhil has a power-domain for a piece of hardware which may be >> voted active by multiple different subsystems (co-processors/execution >> contexts) in the system. >> >> As such, during the powering down sequence we don't wait for the >> power-domain to turn off. But in the event of an error, the recovery >> mechanism relies on waiting for the hardware to settle in a powered off >> state. >> >> The proposal here is to use the reset framework to wait for this state >> to be reached, before continuing with the recovery mechanism in the >> client driver. > I tried to review the series (see my other replies), but I am not sure > I fully understand the consumer part. > > More exactly, when and who is going to pull the reset and at what point? Explained in the other patch. -Akhil. > >> Given our other discussions on quirky behavior, do you have any >> input/suggestions on this? >> >>> Some clients like adreno gpu driver would like to ensure that its gdsc >>> is collapsed at hardware during a gpu reset sequence. This is because it >>> has a votable gdsc which could be ON due to a vote from another subsystem >>> like tz, hyp etc or due to an internal hardware signal. To allow >>> this, gpucc driver can expose an interface to the client driver using >>> reset framework. Using this the client driver can trigger a polling within >>> the gdsc driver. >> @Akhil, this description is fairly generic. As we've reached the state >> where the hardware has settled and we return to the client, what >> prevents it from being powered up again? >> >> Or is it simply a question of it hitting the powered-off state, not >> necessarily staying there? > Okay, so it's indeed the GPU driver that is going to assert/de-assert > the reset at some point. Right? > > That seems like a reasonable approach to me, even if it's a bit > unclear under what conditions that could happen. > > [...] > > Kind regards > Uffe
Re: [Freedreno] [PATCH v7 3/6] clk: qcom: gdsc: Add a reset op to poll gdsc collapse
On 12/8/2022 8:32 PM, Akhil P Oommen wrote:
> On 12/7/2022 9:15 PM, Ulf Hansson wrote:
>> On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen wrote:
>>> Add a reset op compatible function to poll for gdsc collapse. This is
>>> required because:
>>> 1. We don't wait for it to turn OFF at hardware for VOTABLE GDSCs.
>>> 2. There is no way for client drivers (eg. gpu driver) to do
>>> put-with-wait for these gdscs which is required in some scenarios
>>> (eg. GPU recovery).
>> What puzzles me a bit, who is the typical consumer of the reset.
>>
>> I looked at patch4 and tried to figure it out, but let's discuss that
>> in that thread instead. Some more comments, see below.
> https://patchwork.freedesktop.org/patch/498397/
> gpu driver side changes are already merged in upstream. We call this
> interface during a GPU recovery which is supposed to be a rare event.
>>> Signed-off-by: Akhil P Oommen
>>> Reviewed-by: Dmitry Baryshkov
>>> ---
>>>
>>> Changes in v7:
>>> - Update commit message (Bjorn)
>>>
>>> Changes in v2:
>>> - Minor update to function prototype
>>>
>>> drivers/clk/qcom/gdsc.c | 23 +++
>>> drivers/clk/qcom/gdsc.h | 7 +++
>>> 2 files changed, 26 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>> index 7cf5e13..ccef742 100644
>>> --- a/drivers/clk/qcom/gdsc.c
>>> +++ b/drivers/clk/qcom/gdsc.c
>>> @@ -17,6 +17,7 @@
>>> #include
>>> #include
>>> #include "gdsc.h"
>>> +#include "reset.h"
>>>
>>> #define PWR_ON_MASKBIT(31)
>>> #define EN_REST_WAIT_MASK GENMASK_ULL(23, 20)
>>> @@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
>>> return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK,
>>> val);
>>> }
>>>
>>> -static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)
>>> +static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
>>> + s64 timeout_us, unsigned int interval_ms)
>>> {
>>> ktime_t start;
>>>
>>> @@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum
>>> gdsc_status status)
>>> do {
>>> if (gdsc_check_status(sc, status))
>>> return 0;
>>> - } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
>>> + if (interval_ms)
>>> + msleep(interval_ms);
>>> + } while (ktime_us_delta(ktime_get(), start) < timeout_us);
>> Rather than continue to open code this polling loop, would it not make
>> sense to convert the code into using readx_poll_timeout() (or some of
>> its friends).
> I was going for a minimal code churn to get this mainlined easily. I like the
> idea, perhaps we can have a refactor patch if there is consensus.
>
> -Akhil.
>> Down the road, this leads to that the msleep() above should become
>> usleep_range() instead, which seems more correct to me.
Btw, we can optimize this a bit more using 'completion' to minimize CPU
overhead. But that can wait as this is supposed to be a rarely used path. We
don't expect gpu faults often. I would like to see a simpler implementation
upstream first.
-Akhil.
>>
>>> if (gdsc_check_status(sc, status))
>>> return 0;
>>> @@ -189,7 +193,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum
>>> gdsc_status status)
>>> udelay(1);
>>> }
>>>
>>> - ret = gdsc_poll_status(sc, status);
>>> + ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
>>> WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" :
>>> "n");
>>>
>>> if (!ret && status == GDSC_OFF && sc->rsupply) {
>>> @@ -360,7 +364,7 @@ static int _gdsc_disable(struct gdsc *sc)
>>> */
>>> udelay(1);
>>>
>>> - ret = gdsc_poll_status(sc, GDSC_ON);
>>> + ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
>>> if (ret)
>>> return ret;
>>> }
>>> @@ -608,3 +612,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain
>>> *domain)
>>> return 0;
>>> }
>>> EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
>>> +
>>> +int gdsc_wait_for_collapse(void *priv)
>>> +{
>>> + struct gdsc *sc = priv;
>>> + int ret;
>>> +
>>> + ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
>>> + WARN(ret, "%s status stuck at 'on'", sc->pd.name);
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);
>>> diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
>>> index 981a12c..5395f69 100644
>>> --- a/drivers/clk/qcom/gdsc.h
>>> +++ b/drivers/clk/qcom/gdsc.h
>>> @@ -12,6 +12,7 @@
>>> struct regmap;
>>> struct regulator;
>>> struct reset_controller_dev;
>>> +struct qcom_reset_map;
>>>
>>> /**
>>> * struct gdsc - Globally Distributed Switch Controller
>>> @@ -88,6 +89,7 @@ int gdsc_register(struct gdsc_desc *desc, struct
>>> reset_controller_dev *,
>>>
Re: [PATCH v2.5] drm/msm/dsi: switch to DRM_PANEL_BRIDGE #forregzbot
On 13.11.22 11:23, Thorsten Leemhuis wrote: > [Note: this mail is primarily send for documentation purposes and/or for > regzbot, my Linux kernel regression tracking bot. That's why I removed > most or all folks from the list of recipients, but left any that looked > like a mailing lists. These mails usually contain '#forregzbot' in the > subject, to make them easy to spot and filter out.] > > [TLDR: I'm adding this regression report to the list of tracked > regressions; all text from me you find below is based on a few templates > paragraphs you might have encountered already already in similar form.] > > Hi, this is your Linux kernel regression tracker. > > On 11.11.22 16:30, Caleb Connolly wrote: >> >> This patch has caused a regression on 6.1-rc for some devices that use >> DSI panels. The new behaviour results in the DSI controller being >> switched off before the panel unprepare hook is called. As a result, >> panel drivers which call mipi_dsi_dcs_write() or similar in unprepare() >> fail. >> >> I've noticed it specifically on the OnePlus 6 (with upstream Samsung >> s0fef00 panel driver) and the SHIFT6mq with an out of tree driver. > > Thanks for the report. To be sure below issue doesn't fall through the > cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression > tracking bot: > > #regzbot ^introduced 007ac0262b0d > #regzbot title drm: msm: DSI controller being switched off before the > panel unprepare hook is called > #regzbot ignore-activity #regzbot inconclusive: reporter MIA
Re: [PATCH v7 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support
On 12/7/2022 9:16 PM, Ulf Hansson wrote:
> On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen wrote:
>> Allow a consumer driver to poll for cx gdsc collapse through Reset
>> framework.
> Would you mind extending this commit message, to allow us to better
> understand what part is really the consumer part.
Sure. I can do that.
>
> I was expecting the consumer part to be the GPU (adreno) driver, but I
> may have failed to understand correctly. It would be nice to see an
> example of a typical sequence, where the reset is being
> asserted/deasserted, from the consumer point of view. Would you mind
> explaining this a bit more?
https://elixir.bootlin.com/linux/v6.1-rc8/source/drivers/gpu/drm/msm/adreno/a6xx_gpu.c#L1309
You are correct. The consumer is adreno gpu driver. When there is a gpu fault,
these sequences are followed:
1. drop pm_runtime_put() for gpu device which will drops its vote on 'cx'
genpd. line: 1306
2. At this point, there could be vote from either smmu driver (smmu is under
same power domain too) or from other subsystems (tz/hyp).
3. So we call into gdsc driver through reset interface to poll the gdsc
register to ensure it collapsed at least once. Line: 1309
4. Then we turn ON gpu. line:1314.
-Akhil.
>
>> Signed-off-by: Akhil P Oommen
>> Reviewed-by: Dmitry Baryshkov
> Kind regards
> Uffe
>
>> ---
>>
>> (no changes since v3)
>>
>> Changes in v3:
>> - Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)
>>
>> Changes in v2:
>> - Minor update to use the updated custom reset ops implementation
>>
>> drivers/clk/qcom/gpucc-sc7280.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/gpucc-sc7280.c
>> b/drivers/clk/qcom/gpucc-sc7280.c
>> index 9a832f2..fece3f4 100644
>> --- a/drivers/clk/qcom/gpucc-sc7280.c
>> +++ b/drivers/clk/qcom/gpucc-sc7280.c
>> @@ -433,12 +433,22 @@ static const struct regmap_config
>> gpu_cc_sc7280_regmap_config = {
>> .fast_io = true,
>> };
>>
>> +static const struct qcom_reset_ops cx_gdsc_reset = {
>> + .reset = gdsc_wait_for_collapse,
>> +};
>> +
>> +static const struct qcom_reset_map gpucc_sc7280_resets[] = {
>> + [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
>> +};
>> +
>> static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
>> .config = _cc_sc7280_regmap_config,
>> .clks = gpu_cc_sc7280_clocks,
>> .num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
>> .gdscs = gpu_cc_sc7180_gdscs,
>> .num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
>> + .resets = gpucc_sc7280_resets,
>> + .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
>> };
>>
>> static const struct of_device_id gpu_cc_sc7280_match_table[] = {
>> --
>> 2.7.4
>>
Re: [PATCH v7 3/6] clk: qcom: gdsc: Add a reset op to poll gdsc collapse
On 12/7/2022 9:15 PM, Ulf Hansson wrote:
> On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen wrote:
>> Add a reset op compatible function to poll for gdsc collapse. This is
>> required because:
>> 1. We don't wait for it to turn OFF at hardware for VOTABLE GDSCs.
>> 2. There is no way for client drivers (eg. gpu driver) to do
>> put-with-wait for these gdscs which is required in some scenarios
>> (eg. GPU recovery).
> What puzzles me a bit, who is the typical consumer of the reset.
>
> I looked at patch4 and tried to figure it out, but let's discuss that
> in that thread instead. Some more comments, see below.
https://patchwork.freedesktop.org/patch/498397/
gpu driver side changes are already merged in upstream. We call this interface
during a GPU recovery which is supposed to be a rare event.
>
>> Signed-off-by: Akhil P Oommen
>> Reviewed-by: Dmitry Baryshkov
>> ---
>>
>> Changes in v7:
>> - Update commit message (Bjorn)
>>
>> Changes in v2:
>> - Minor update to function prototype
>>
>> drivers/clk/qcom/gdsc.c | 23 +++
>> drivers/clk/qcom/gdsc.h | 7 +++
>> 2 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>> index 7cf5e13..ccef742 100644
>> --- a/drivers/clk/qcom/gdsc.c
>> +++ b/drivers/clk/qcom/gdsc.c
>> @@ -17,6 +17,7 @@
>> #include
>> #include
>> #include "gdsc.h"
>> +#include "reset.h"
>>
>> #define PWR_ON_MASKBIT(31)
>> #define EN_REST_WAIT_MASK GENMASK_ULL(23, 20)
>> @@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
>> return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK,
>> val);
>> }
>>
>> -static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)
>> +static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
>> + s64 timeout_us, unsigned int interval_ms)
>> {
>> ktime_t start;
>>
>> @@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum
>> gdsc_status status)
>> do {
>> if (gdsc_check_status(sc, status))
>> return 0;
>> - } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
>> + if (interval_ms)
>> + msleep(interval_ms);
>> + } while (ktime_us_delta(ktime_get(), start) < timeout_us);
> Rather than continue to open code this polling loop, would it not make
> sense to convert the code into using readx_poll_timeout() (or some of
> its friends).
I was going for a minimal code churn to get this mainlined easily. I like the
idea, perhaps we can have a refactor patch if there is consensus.
-Akhil.
>
> Down the road, this leads to that the msleep() above should become
> usleep_range() instead, which seems more correct to me.
>
>> if (gdsc_check_status(sc, status))
>> return 0;
>> @@ -189,7 +193,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum
>> gdsc_status status)
>> udelay(1);
>> }
>>
>> - ret = gdsc_poll_status(sc, status);
>> + ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
>> WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" :
>> "n");
>>
>> if (!ret && status == GDSC_OFF && sc->rsupply) {
>> @@ -360,7 +364,7 @@ static int _gdsc_disable(struct gdsc *sc)
>> */
>> udelay(1);
>>
>> - ret = gdsc_poll_status(sc, GDSC_ON);
>> + ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
>> if (ret)
>> return ret;
>> }
>> @@ -608,3 +612,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain
>> *domain)
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
>> +
>> +int gdsc_wait_for_collapse(void *priv)
>> +{
>> + struct gdsc *sc = priv;
>> + int ret;
>> +
>> + ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
>> + WARN(ret, "%s status stuck at 'on'", sc->pd.name);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);
>> diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
>> index 981a12c..5395f69 100644
>> --- a/drivers/clk/qcom/gdsc.h
>> +++ b/drivers/clk/qcom/gdsc.h
>> @@ -12,6 +12,7 @@
>> struct regmap;
>> struct regulator;
>> struct reset_controller_dev;
>> +struct qcom_reset_map;
>>
>> /**
>> * struct gdsc - Globally Distributed Switch Controller
>> @@ -88,6 +89,7 @@ int gdsc_register(struct gdsc_desc *desc, struct
>> reset_controller_dev *,
>> struct regmap *);
>> void gdsc_unregister(struct gdsc_desc *desc);
>> int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain);
>> +int gdsc_wait_for_collapse(void *priv);
>> #else
>> static inline int gdsc_register(struct gdsc_desc *desc,
>> struct reset_controller_dev *rcdev,
>> @@ -97,5 +99,10 @@ static inline int gdsc_register(struct gdsc_desc *desc,
>> }
>>
>> static
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On 12/8/2022 7:10 PM, Ulf Hansson wrote: > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote: >> On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote: >>> On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote: On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: @Ulf, Akhil has a power-domain for a piece of hardware which may be voted active by multiple different subsystems (co-processors/execution contexts) in the system. As such, during the powering down sequence we don't wait for the power-domain to turn off. But in the event of an error, the recovery mechanism relies on waiting for the hardware to settle in a powered off state. The proposal here is to use the reset framework to wait for this state to be reached, before continuing with the recovery mechanism in the client driver. >>> I tried to review the series (see my other replies), but I am not sure >>> I fully understand the consumer part. >>> >>> More exactly, when and who is going to pull the reset and at what point? >>> Given our other discussions on quirky behavior, do you have any input/suggestions on this? > Some clients like adreno gpu driver would like to ensure that its gdsc > is collapsed at hardware during a gpu reset sequence. This is because it > has a votable gdsc which could be ON due to a vote from another subsystem > like tz, hyp etc or due to an internal hardware signal. To allow > this, gpucc driver can expose an interface to the client driver using > reset framework. Using this the client driver can trigger a polling within > the gdsc driver. @Akhil, this description is fairly generic. As we've reached the state where the hardware has settled and we return to the client, what prevents it from being powered up again? Or is it simply a question of it hitting the powered-off state, not necessarily staying there? >>> Okay, so it's indeed the GPU driver that is going to assert/de-assert >>> the reset at some point. Right? >>> >>> That seems like a reasonable approach to me, even if it's a bit >>> unclear under what conditions that could happen. >>> >> Generally the disable-path of the power-domain does not check that the >> power-domain is actually turned off, because the status might indicate >> that the hardware is voting for the power-domain to be on. > Is there a good reason why the HW needs to vote too, when the GPU > driver is already in control? > > Or perhaps that depends on the running use case? This power domain can be voted to be ON from other subsystems outside of linux kernel like secure os, hypervisor etc through separate vote registers. So it is not completely under the control of linux clk driver. Linux clk driver can only vote it to be kept ON, check current status etc, but cannot force it to be OFF. I believe this is why it is a votable gdsc in linux-clk driver. Just a general clarification. GPU has mainly 2 power domains: (1) CX which is shared by GPU and its SMMU, (2) GX which is GPU specific and managed mostly by a power management core within GPU. This patch series is to allow gpu driver to ensure that CX gdsc has collapsed which in turn will reset GPU's internal state. > >> As part of the recovery of the GPU after some fatal fault, the GPU >> driver does something which will cause the hardware votes for the >> power-domain to be let go, and then the driver does pm_runtime_put(). > Okay. That "something", sounds like a device specific setting for the > corresponding gdsc, right? > > So somehow the GPU driver needs to manage that setting, right? Clarified about this above. > >> But in this case the GPU driver wants to ensure that the power-domain is >> actually powered down, before it does pm_runtime_get() again. To ensure >> that the hardware lost its state... > I see. > >> The proposal here is to use a reset to reach into the power-domain >> provider and wait for the hardware to be turned off, before the GPU >> driver attempts turning the power-domain on again. >> >> >> In other words, there is no reset. This is a hack to make a normally >> asynchronous pd.power_off() to be synchronous in this particular case. Not really. Because other non-linux subsystems are involved here for CX gdsc, we need a way to poll the gdsc register to ensure that it has indeed collapsed before gpu driver continue with re-initialization of gpu. It is either this approach using 'reset' framework or plumbing a new path from gpu driver to gpucc-gdsc driver to poll the collapse status. I went with the 'reset' approach as per the consensus here: https://patchwork.freedesktop.org/patch/493143/ -Akhil. > Alright, assuming I understood your clarifications above correctly > (thanks!), I think I have got a much better picture now. > > Rather than abusing the reset interface, I think we should manage this > through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU
[PATCH v3 1/1] dt-bindings: lcdif: Fix constraints for imx8mp
i.MX8MP uses 3 clocks, so soften the restrictions for clocks & clock-names.
This SoC requires a power-domain for this peripheral to use. Add it as
a required property.
Fixes: f5419cb0743f ("dt-bindings: lcdif: Add compatible for i.MX8MP")
Signed-off-by: Alexander Stein
---
Changes in v3:
* Removed power-domains minItems: 1 constraint
Changes in v2:
* Squash both patches into one
* Split the conditionals from fsl,imx6sx-lcdif
* Mark power-domains as required for fsl,imx8mp-lcdif
* Ignored the A-b & R-b due to reorganization
.../bindings/display/fsl,lcdif.yaml | 29 ++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 876015a44a1e6..f449cfc767899 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -52,6 +52,9 @@ properties:
interrupts:
maxItems: 1
+ power-domains:
+maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: The LCDIF output port
@@ -81,7 +84,31 @@ allOf:
maxItems: 3
required:
- clock-names
-else:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8mp-lcdif
+then:
+ properties:
+clocks:
+ minItems: 3
+ maxItems: 3
+clock-names:
+ minItems: 3
+ maxItems: 3
+ required:
+- clock-names
+- power-domains
+ - if:
+ not:
+properties:
+ compatible:
+contains:
+ enum:
+- fsl,imx6sx-lcdif
+- fsl,imx8mp-lcdif
+then:
properties:
clocks:
maxItems: 1
--
2.34.1
Re: [Intel-gfx] [PATCH v8 22/22] drm/i915/vm_bind: Support capture of persistent mappings
On Tue, Dec 06, 2022 at 05:40:54PM +, Matthew Auld wrote:
On 01/12/2022 18:43, Niranjana Vishwanathapura wrote:
On Thu, Dec 01, 2022 at 07:27:31AM -0800, Niranjana Vishwanathapura wrote:
On Thu, Dec 01, 2022 at 10:49:15AM +, Matthew Auld wrote:
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 ++
include/uapi/drm/i915_drm.h | 3 ++-
7 files changed, 43 insertions(+), 1 deletion(-)
diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..50969613daf6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,11 @@ static void i915_gem_vm_bind_remove(struct
i915_vma *vma, bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ spin_unlock(>vm->vm_capture_lock);
+
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +362,12 @@ static int i915_gem_vm_bind_obj(struct
i915_address_space *vm,
continue;
}
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ spin_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ spin_unlock(>vm_capture_lock);
+ }
+
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index ebf6830574a0..bdabe13fc30e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,9 @@ void i915_address_space_init(struct
i915_address_space *vm, int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+ INIT_LIST_HEAD(>vm_capture_list);
+ spin_lock_init(>vm_capture_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 87e5b6568a00..8e4ddd073348 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,11 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private
objects */
struct drm_i915_gem_object *root_obj;
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ spinlock_t vm_capture_lock;
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..3b2b12a739f7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct
intel_engine_capture_vma *next,
return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+ struct i915_address_space *vm, gfp_t gfp)
+{
+ struct i915_vma *vma;
+
+ spin_lock(>vm_capture_lock);
Does it make sense to move this into the eb3 submission stage,
like we do for eb2? IIRC the gfp flags here are quite limiting
due to potentially being in a fence critical section. If we can
use rq->capture_list for eb3, we shouldn't need to change much
here?
But that will add latency on submission path as we will have to iterate
over capture_list in each submission. Besides, unlike eb2 case, we can't
just transfer the list to rq->capture_list as we will have to do this
for each submission. It was discussed long time back and decided not to
bother the fast path (submision) scenario with this error capture which
is only required upon gpu hang (slow path).
Maybe add some of this to the commit message, just to give a bit more
back story/history. From my pov I'm coming into this semi-blind.
Ok, will add.
Also there is the existing CONFIG_DRM_I915_CAPTURE_ERROR. Should
we take that into account?
Ok, will fix.
+ /* vma->resource must be valid here as persistent vmas
are bound */
+ list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+ capture = capture_vma_snapshot(capture, vma->resource,
+ gfp, "user");
+ spin_unlock(>vm_capture_lock);
+
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote: > > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote: > > On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson wrote: > > > > > > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > > > > > > > > > > @Ulf, Akhil has a power-domain for a piece of hardware which may be > > > voted active by multiple different subsystems (co-processors/execution > > > contexts) in the system. > > > > > > As such, during the powering down sequence we don't wait for the > > > power-domain to turn off. But in the event of an error, the recovery > > > mechanism relies on waiting for the hardware to settle in a powered off > > > state. > > > > > > The proposal here is to use the reset framework to wait for this state > > > to be reached, before continuing with the recovery mechanism in the > > > client driver. > > > > I tried to review the series (see my other replies), but I am not sure > > I fully understand the consumer part. > > > > More exactly, when and who is going to pull the reset and at what point? > > > > > > > > Given our other discussions on quirky behavior, do you have any > > > input/suggestions on this? > > > > > > > Some clients like adreno gpu driver would like to ensure that its gdsc > > > > is collapsed at hardware during a gpu reset sequence. This is because it > > > > has a votable gdsc which could be ON due to a vote from another > > > > subsystem > > > > like tz, hyp etc or due to an internal hardware signal. To allow > > > > this, gpucc driver can expose an interface to the client driver using > > > > reset framework. Using this the client driver can trigger a polling > > > > within > > > > the gdsc driver. > > > > > > @Akhil, this description is fairly generic. As we've reached the state > > > where the hardware has settled and we return to the client, what > > > prevents it from being powered up again? > > > > > > Or is it simply a question of it hitting the powered-off state, not > > > necessarily staying there? > > > > Okay, so it's indeed the GPU driver that is going to assert/de-assert > > the reset at some point. Right? > > > > That seems like a reasonable approach to me, even if it's a bit > > unclear under what conditions that could happen. > > > > Generally the disable-path of the power-domain does not check that the > power-domain is actually turned off, because the status might indicate > that the hardware is voting for the power-domain to be on. Is there a good reason why the HW needs to vote too, when the GPU driver is already in control? Or perhaps that depends on the running use case? > > As part of the recovery of the GPU after some fatal fault, the GPU > driver does something which will cause the hardware votes for the > power-domain to be let go, and then the driver does pm_runtime_put(). Okay. That "something", sounds like a device specific setting for the corresponding gdsc, right? So somehow the GPU driver needs to manage that setting, right? > > But in this case the GPU driver wants to ensure that the power-domain is > actually powered down, before it does pm_runtime_get() again. To ensure > that the hardware lost its state... I see. > > The proposal here is to use a reset to reach into the power-domain > provider and wait for the hardware to be turned off, before the GPU > driver attempts turning the power-domain on again. > > > In other words, there is no reset. This is a hack to make a normally > asynchronous pd.power_off() to be synchronous in this particular case. Alright, assuming I understood your clarifications above correctly (thanks!), I think I have got a much better picture now. Rather than abusing the reset interface, I think we should manage this through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU driver should register its corresponding device for them (dev_pm_genpd_add_notifier()). The trick however, is to make the behaviour of the power-domain for the gdsc (the genpd->power_off() callback) conditional on whether the HW is configured to vote or not. If the HW can vote, it should not poll for the state - and vice versa when the HW can't vote. Would this work? Kind regards Uffe
Re: [PATCH 1/2] dt-bindings: lcdif: Fix clock constraints for imx8mp
On 12/8/22 07:31, Alexander Stein wrote:
Hello Marek,
Am Mittwoch, 7. Dezember 2022, 16:59:50 CET schrieb Marek Vasut:
On 12/7/22 16:13, Alexander Stein wrote:
i.MX8MP uses 3 clocks, so soften the restrictions for clocks &
clock-names.
Fixes: f5419cb0743f ("dt-bindings: lcdif: Add compatible for i.MX8MP")
Signed-off-by: Alexander Stein
---
Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index
876015a44a1e6..793e8eccf8b8b 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -70,7 +70,9 @@ allOf:
properties:
compatible:
contains:
-const: fsl,imx6sx-lcdif
+enum:
+ - fsl,imx6sx-lcdif
+ - fsl,imx8mp-lcdif
then:
properties:
clocks:
Reviewed-by: Marek Vasut
Thanks!
btw you might want to update the clock-names and clock proerty order in
imx8mp.dtsi to match the clock-names order in these bindings.
The lcdif nodes are not yet in linux-next ;-) So its probably a local commit
on your side. But yes, the upcoming patches will address this.
Ah, right, seems they are still pending HDMI and DSIM addition. Sorry
for the noise.
Re: [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use
On Thu, Dec 08, 2022 at 02:54:45PM +0200, Andy Shevchenko wrote: > On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote: > > Some of the existing users, and definitely will be new ones, want to > > count existing nodes in the list. Provide a generic API for that by > > moving code from i915 to list.h. > > Greg, I believe this one is ready to be taken. Or please tell me what I need > to do. Wait for me to get through the current backlog of patches that I have in my review queue. Odds are, it will have to wait until after 6.2-rc1 is out based on when 6.1 is going to be released. Don't worry, it's not lost. thanks, greg k-h
Re: [PATCH v5 1/4] i915: Move list_count() to list.h as list_count_nodes() for broader use
On Wed, Nov 30, 2022 at 03:48:35PM +0200, Andy Shevchenko wrote: > Some of the existing users, and definitely will be new ones, want to > count existing nodes in the list. Provide a generic API for that by > moving code from i915 to list.h. Greg, I believe this one is ready to be taken. Or please tell me what I need to do. -- With Best Regards, Andy Shevchenko
Re: [RESEND PATCH linux-next v2 00/10] drm: Remove some obsolete drivers(tdfx, mga, i810, savage, r128, sis, via)
On 03 12月 22 18:22:51, Cai Huoqing wrote:
> Commit 399516ab0fee ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers")
> marked these drivers obsolete 7 years ago.
> And the mesa UMD of these drm drivers already in deprecated list
> in the link: https://docs.mesa3d.org/systems.html
>
> 3dfx Glide-->driver/gpu/drm/tdfx
> Matrox-->driver/gpu/drm/mga
> Intel i810-->driver/gpu/drm/i810
> S3 Savage-->drivers/gpu/drm/savage
> ATI Rage 128->drivers/gpu/drm/r128
> Silicon Integrated Systems->drivers/gpu/drm/sis
> VIA Unichrome->drivers/gpu/drm/via
>
> v1->v2:
> 1.Add drm via driver to the patchset.
> 2.Remove related drm_pciids.
> 3.Remove related drm uapi header files.
> 4.split to series avoid large patch email.
Just ping these patch series.
The v1 comments here,
https://lore.kernel.org/lkml/39d8ac1a-d92f-7cdc-14cd-944342f78...@suse.de/
Thanks,
Cai
>
> Cai Huoqing (10):
> drm: Remove the obsolete driver-i810
> drm: Remove the obsolete driver-mga
> drm: Remove the obsolete driver-r128
> drm: Remove the obsolete driver-savage
> drm: Remove the obsolete driver-sis
> drm: Remove the obsolete driver-tdfx
> drm: Remove the obsolete driver-via
> drm: Add comments to Kconfig
> drm: Remove some obsolete drm pciids(tdfx, mga, i810, savage, r128,
> sis, via)
> MAINTAINERS: Remove some obsolete drivers info(tdfx, mga, i810,
> savage, r128, sis)
>
> MAINTAINERS | 29 -
> drivers/gpu/drm/Kconfig | 59 +-
> drivers/gpu/drm/Makefile |7 -
> drivers/gpu/drm/i810/Makefile |8 -
> drivers/gpu/drm/i810/i810_dma.c | 1266 -
> drivers/gpu/drm/i810/i810_drv.c | 101 -
> drivers/gpu/drm/i810/i810_drv.h | 246 --
> drivers/gpu/drm/mga/Makefile | 11 -
> drivers/gpu/drm/mga/mga_dma.c | 1168
> drivers/gpu/drm/mga/mga_drv.c | 104 -
> drivers/gpu/drm/mga/mga_drv.h | 685 -
> drivers/gpu/drm/mga/mga_ioc32.c | 197 --
> drivers/gpu/drm/mga/mga_irq.c | 169 --
> drivers/gpu/drm/mga/mga_state.c | 1099
> drivers/gpu/drm/mga/mga_warp.c| 167 --
> drivers/gpu/drm/r128/Makefile | 10 -
> drivers/gpu/drm/r128/ati_pcigart.c| 228 --
> drivers/gpu/drm/r128/ati_pcigart.h| 31 -
> drivers/gpu/drm/r128/r128_cce.c | 944 ---
> drivers/gpu/drm/r128/r128_drv.c | 116 -
> drivers/gpu/drm/r128/r128_drv.h | 544
> drivers/gpu/drm/r128/r128_ioc32.c | 199 --
> drivers/gpu/drm/r128/r128_irq.c | 118 -
> drivers/gpu/drm/r128/r128_state.c | 1641 ---
> drivers/gpu/drm/savage/Makefile |9 -
> drivers/gpu/drm/savage/savage_bci.c | 1082
> drivers/gpu/drm/savage/savage_drv.c | 91 -
> drivers/gpu/drm/savage/savage_drv.h | 580
> drivers/gpu/drm/savage/savage_state.c | 1169
> drivers/gpu/drm/sis/Makefile | 10 -
> drivers/gpu/drm/sis/sis_drv.c | 143 -
> drivers/gpu/drm/sis/sis_drv.h | 80 -
> drivers/gpu/drm/sis/sis_mm.c | 363 ---
> drivers/gpu/drm/tdfx/Makefile |8 -
> drivers/gpu/drm/tdfx/tdfx_drv.c | 90 -
> drivers/gpu/drm/tdfx/tdfx_drv.h | 47 -
> drivers/gpu/drm/via/Makefile |8 -
> drivers/gpu/drm/via/via_3d_reg.h | 1771
> drivers/gpu/drm/via/via_dri1.c| 3630 -
> include/drm/drm_pciids.h | 112 -
> include/uapi/drm/i810_drm.h | 292 --
> include/uapi/drm/mga_drm.h| 429 ---
> include/uapi/drm/r128_drm.h | 336 ---
> include/uapi/drm/savage_drm.h | 220 --
> include/uapi/drm/sis_drm.h| 77 -
> include/uapi/drm/via_drm.h| 282 --
> 46 files changed, 1 insertion(+), 19975 deletions(-)
> delete mode 100644 drivers/gpu/drm/i810/Makefile
> delete mode 100644 drivers/gpu/drm/i810/i810_dma.c
> delete mode 100644 drivers/gpu/drm/i810/i810_drv.c
> delete mode 100644 drivers/gpu/drm/i810/i810_drv.h
> delete mode 100644 drivers/gpu/drm/mga/Makefile
> delete mode 100644 drivers/gpu/drm/mga/mga_dma.c
> delete mode 100644 drivers/gpu/drm/mga/mga_drv.c
> delete mode 100644 drivers/gpu/drm/mga/mga_drv.h
> delete mode 100644 drivers/gpu/drm/mga/mga_ioc32.c
> delete mode 100644 drivers/gpu/drm/mga/mga_irq.c
> delete mode 100644 drivers/gpu/drm/mga/mga_state.c
> delete mode 100644 drivers/gpu/drm/mga/mga_warp.c
> delete mode 100644 drivers/gpu/drm/r128/Makefile
> delete mode 100644 drivers/gpu/drm/r128/ati_pcigart.c
> delete mode 100644 drivers/gpu/drm/r128/ati_pcigart.h
> delete mode 100644 drivers/gpu/drm/r128/r128_cce.c
> delete mode 100644 drivers/gpu/drm/r128/r128_drv.c
> delete mode 100644 drivers/gpu/drm/r128/r128_drv.h
> delete mode 100644 drivers/gpu/drm/r128/r128_ioc32.c
> delete mode 100644 drivers/gpu/drm/r128/r128_irq.c
> delete mode 100644 drivers/gpu/drm/r128/r128_state.c
> delete mode
Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization
On 08.12.2022 12:32, Jagan Teki wrote:
> On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
> wrote:
>> On 05.12.22 16:37, Frieder Schrempf wrote:
>>> Hi Dave,
>>>
>>> On 05.12.22 16:20, Dave Stevenson wrote:
Hi Frieder
On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
wrote:
> On 02.12.22 15:55, Dave Stevenson wrote:
>> Hi Marek
>>
>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
>>> On 12/2/22 11:52, Marek Szyprowski wrote:
Hi,
Sorry for delay, I was on a sick leave last 2 weeks.
On 28.11.2022 15:43, Jagan Teki wrote:
> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
On 11/17/22 14:04, Marek Szyprowski wrote:
> On 17.11.2022 05:58, Marek Vasut wrote:
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> DSI host initialization handling in previous exynos dsi driver
>>> has
>>> some pitfalls. It initializes the host during host transfer()
>>> hook
>>> that is indeed not the desired call flow for I2C and any other
>>> DSI
>>> configured downstream bridges.
>>>
>>> Host transfer() is usually triggered for downstream DSI panels
>>> or
>>> bridges and I2C-configured-DSI bridges miss these host
>>> initialization
>>> as these downstream bridges use bridge operations hooks like
>>> pre_enable,
>>> and enable in order to initialize or set up the host.
>>>
>>> This patch is trying to handle the host init handler to satisfy
>>> all
>>> downstream panels and bridges. Added the
>>> DSIM_STATE_REINITIALIZED state
>>> flag to ensure that host init is also done on first cmd
>>> transfer, this
>>> helps existing DSI panels work on exynos platform (form Marek
>>> Szyprowski).
>>>
>>> v8, v7, v6, v5:
>>> * none
>>>
>>> v4:
>>> * update init handling to ensure host init done on first cmd
>>> transfer
>>>
>>> v3:
>>> * none
>>>
>>> v2:
>>> * check initialized state in samsung_dsim_init
>>>
>>> v1:
>>> * keep DSI init in host transfer
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Signed-off-by: Jagan Teki
>>> ---
>>>drivers/gpu/drm/bridge/samsung-dsim.c | 25
>>> +
>>>include/drm/bridge/samsung-dsim.h | 5 +++--
>>>2 files changed, 20 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1234,12 +1234,17 @@ static void
>>> samsung_dsim_disable_irq(struct
>>> samsung_dsim *dsi)
>>>disable_irq(dsi->irq);
>>>}
>>>-static int samsung_dsim_init(struct samsung_dsim *dsi)
>>> +static int samsung_dsim_init(struct samsung_dsim *dsi,
>>> unsigned int
>>> flag)
>>>{
>>>const struct samsung_dsim_driver_data *driver_data =
>>> dsi->driver_data;
>>>+if (dsi->state & flag)
>>> +return 0;
>>> +
>>>samsung_dsim_reset(dsi);
>>> -samsung_dsim_enable_irq(dsi);
>>> +
>>> +if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +samsung_dsim_enable_irq(dsi);
>>> if (driver_data->reg_values[RESET_TYPE] ==
>>> DSIM_FUNCRST)
>>>samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) -
>>> 1);
>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>> samsung_dsim *dsi)
>>>samsung_dsim_set_phy_ctrl(dsi);
>>>samsung_dsim_init_link(dsi);
>>>+dsi->state |= flag;
>>> +
>>>return 0;
>>>}
>>>@@ -1269,6 +1276,10 @@ static void
>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>}
>>> dsi->state |= DSIM_STATE_ENABLED;
>>> +
>>> +ret =
[PATCH] drm/amd/display: Fix spelling mistake: "dram_clk_chanage" -> "dram_clk_change"
There is a spelling mistake in the struct field dram_clk_chanage. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
.../drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hubbub.c | 8
drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h | 2 +-
7 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
index 0f746bb4e500..d51f1ce02874 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
@@ -55,7 +55,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_A);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_A);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_A);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_A);
s = >sets[1];
s->wm_set = 1;
@@ -65,7 +65,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_B);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_B);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_B);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_B);
s = >sets[2];
s->wm_set = 2;
@@ -75,7 +75,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_C);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_C);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_C);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_C);
s = >sets[3];
s->wm_set = 3;
@@ -85,7 +85,7 @@ void hubbub1_wm_read_state(struct hubbub *hubbub,
s->sr_enter = REG_READ(DCHUBBUB_ARB_ALLOW_SR_ENTER_WATERMARK_D);
s->sr_exit = REG_READ(DCHUBBUB_ARB_ALLOW_SR_EXIT_WATERMARK_D);
}
- s->dram_clk_chanage =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_D);
+ s->dram_clk_change =
REG_READ(DCHUBBUB_ARB_ALLOW_DRAM_CLK_CHANGE_WATERMARK_D);
}
void hubbub1_allow_self_refresh_control(struct hubbub *hubbub, bool allow)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index c8ec11839b4d..fe2023f18b7d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -159,7 +159,7 @@ static void dcn10_log_hubbub_state(struct dc *dc,
DTN_INFO_MICRO_SEC(s->pte_meta_urgent);
DTN_INFO_MICRO_SEC(s->sr_enter);
DTN_INFO_MICRO_SEC(s->sr_exit);
- DTN_INFO_MICRO_SEC(s->dram_clk_chanage);
+ DTN_INFO_MICRO_SEC(s->dram_clk_change);
DTN_INFO("\n");
}
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
index e8b6065fffad..a0f8e31d2adc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer_debug.c
@@ -83,7 +83,7 @@ static unsigned int dcn10_get_hubbub_state(struct dc *dc,
char *pBuf, unsigned i
memset(, 0, sizeof(struct dcn_hubbub_wm));
dc->res_pool->hubbub->funcs->wm_read_state(dc->res_pool->hubbub, );
- chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n");
+ chars_printed = snprintf_count(pBuf, remaining_buffer,
"wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_change\n");
remaining_buffer -= chars_printed;
pBuf += chars_printed;
@@ -98,7 +98,7 @@ static unsigned int dcn10_get_hubbub_state(struct dc *dc,
char *pBuf, unsigned i
(s->pte_meta_urgent * frac) / ref_clk_mhz / frac,
(s->pte_meta_urgent * frac) / ref_clk_mhz % frac,
(s->sr_enter * frac) / ref_clk_mhz / frac, (s->sr_enter
* frac) / ref_clk_mhz % frac,
(s->sr_exit * frac) / ref_clk_mhz / frac, (s->sr_exit *
frac) / ref_clk_mhz % frac,
- (s->dram_clk_chanage * frac) / ref_clk_mhz / frac,
(s->dram_clk_chanage * frac) / ref_clk_mhz % frac);
+
Re: [PATCH v3 2/6] drm: use new debugfs device-centered functions on DRM core files
On Wed, Dec 07, 2022 at 10:23:21AM -0300, Maíra Canal wrote: > Replace the use of drm_debugfs_create_files() with the new > drm_debugfs_add_files() function in all DRM core files, centering the > debugfs files management on the drm_device instead of drm_minor. > > Signed-off-by: Maíra Canal Reviewed-by: Maxime Ripard signature.asc Description: PGP signature
Re: [PATCH v3 1/6] drm/debugfs: create device-centered debugfs functions
On Wed, Dec 07, 2022 at 10:23:20AM -0300, Maíra Canal wrote: > Introduce the ability to track requests for the addition of DRM debugfs > files at any time and have them added all at once during > drm_dev_register(). > > Drivers can add DRM debugfs files to a device-managed list and, during > drm_dev_register(), all added files will be created at once. > > Now, the drivers can use the functions drm_debugfs_add_file() and > drm_debugfs_add_files() to create DRM debugfs files instead of using the > drm_debugfs_create_files() function. > > Co-developed-by: Wambui Karuga > Signed-off-by: Wambui Karuga > Signed-off-by: Maíra Canal Reviewed-by: Maxime Ripard Maxime signature.asc Description: PGP signature
Re: [PATCH v3 3/6] drm/vc4: use new debugfs device-centered functions
On Wed, Dec 07, 2022 at 10:23:22AM -0300, Maíra Canal wrote: > Currently, vc4 has its own debugfs infrastructure that adds the debugfs > files on drm_dev_register(). With the introduction of the new debugfs, > functions, replace the vc4 debugfs structure with the DRM debugfs > device-centered function, drm_debugfs_add_file(). > > Moreover, remove the explicit error handling of debugfs related functions, > considering that the only failure mode is -ENOMEM and also that error > handling is not recommended for debugfs functions, as pointed out in [1]. > > [1] https://lore.kernel.org/all/ywamzdrwnat6w...@kroah.com/ > > Signed-off-by: Maíra Canal Reviewed-by: Maxime Ripard Maxime signature.asc Description: PGP signature
Re: [PATCH] drm: mali-dp: Add check for kzalloc
Hi Jiasheng,
I appreciate the effort you have put into this and I find nothing wrong with the
intention of the patch. However, I don't intend to move base from being the
first
member of the malidp_mw_connector_state struct as it has other benefits in the
code
and we can use container_of() in implementation of generic APIs. As Robin has
rightly
pointed, it is unlikely that a compiler will dereference the pointer before
doing
offset_of(), so having mw_state == NULL is safe, even if quirky.
So I'm going to thank you for the patch but I will not merge it.
As a side comment, please use --in-reply-to and link to previous email when
re-sending
patches with small spelling fixes as otherwise it gets confusing on which email
is the last
one and it also relies on the servers delivering messages in the order you've
sent,
not always a strong guarantee.
Best regards,
Liviu
On Thu, Dec 08, 2022 at 11:16:21AM +0800, Jiasheng Jiang wrote:
> As kzalloc may fail and return NULL pointer, the "mw_state" can be NULL.
> If the layout of struct malidp_mw_connector_state ever changes, it
> will cause NULL poineter derefernce of "_state->base".
> Therefore, the "mw_state" should be checked whether it is NULL in order
> to improve the robust.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Jiasheng Jiang
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index ef76d0e6ee2f..fe4474c2ddcf 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -72,7 +72,11 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> + else
> + __drm_atomic_helper_connector_reset(connector, NULL);
> }
>
> static enum drm_connector_status
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/gud: Fix missing include
Den 08.12.2022 09.15, skrev Thomas Zimmermann:
> Hi
>
> Am 07.12.22 um 20:51 schrieb Noralf Trønnes via B4 Submission Endpoint:
>> From: Noralf Trønnes
>>
>> Add missing vmalloc.h include.
>>
>> Fixes: c17d048609bf ("drm/gud: Use the shadow plane helper")
>> Reported-by: kernel test robot
>> Signed-off-by: Noralf Trønnes
>
> Reviewed-by: Thomas Zimmermann
>
Thanks.
> The missing-vmalloc() error is a real classic. :( Some architectures
> declare the function and some don't.
>
Yeah, I think I've seen this before. Good we have the bots to cover the
corner cases.
Noralf.
> Best regards
> Thomas
>
>> ---
>> drivers/gpu/drm/gud/gud_pipe.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/gud/gud_pipe.c
>> b/drivers/gpu/drm/gud/gud_pipe.c
>> index 62c43d3632d4..dc16a92625d4 100644
>> --- a/drivers/gpu/drm/gud/gud_pipe.c
>> +++ b/drivers/gpu/drm/gud/gud_pipe.c
>> @@ -5,6 +5,7 @@
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> ---
>> base-commit: 5ad8e63ebba3d5a0730b43180b200e41eeb9409c
>> change-id: 20221207-gud-missing-include-9ccf56382f8a
>>
>> Best regards,
>
Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization
On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
wrote:
>
> On 05.12.22 16:37, Frieder Schrempf wrote:
> > Hi Dave,
> >
> > On 05.12.22 16:20, Dave Stevenson wrote:
> >> Hi Frieder
> >>
> >> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> >> wrote:
> >>>
> >>> On 02.12.22 15:55, Dave Stevenson wrote:
> Hi Marek
>
> On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
> >
> > On 12/2/22 11:52, Marek Szyprowski wrote:
> >> Hi,
> >>
> >> Sorry for delay, I was on a sick leave last 2 weeks.
> >>
> >> On 28.11.2022 15:43, Jagan Teki wrote:
> >>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
> On 11/23/22 21:09, Jagan Teki wrote:
> > On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
> >> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>> On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
> > DSI host initialization handling in previous exynos dsi driver
> > has
> > some pitfalls. It initializes the host during host transfer()
> > hook
> > that is indeed not the desired call flow for I2C and any other
> > DSI
> > configured downstream bridges.
> >
> > Host transfer() is usually triggered for downstream DSI panels
> > or
> > bridges and I2C-configured-DSI bridges miss these host
> > initialization
> > as these downstream bridges use bridge operations hooks like
> > pre_enable,
> > and enable in order to initialize or set up the host.
> >
> > This patch is trying to handle the host init handler to satisfy
> > all
> > downstream panels and bridges. Added the
> > DSIM_STATE_REINITIALIZED state
> > flag to ensure that host init is also done on first cmd
> > transfer, this
> > helps existing DSI panels work on exynos platform (form Marek
> > Szyprowski).
> >
> > v8, v7, v6, v5:
> > * none
> >
> > v4:
> > * update init handling to ensure host init done on first cmd
> > transfer
> >
> > v3:
> > * none
> >
> > v2:
> > * check initialized state in samsung_dsim_init
> >
> > v1:
> > * keep DSI init in host transfer
> >
> > Signed-off-by: Marek Szyprowski
> > Signed-off-by: Jagan Teki
> > ---
> > drivers/gpu/drm/bridge/samsung-dsim.c | 25
> > +
> > include/drm/bridge/samsung-dsim.h | 5 +++--
> > 2 files changed, 20 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index bb1f45fd5a88..ec7e01ae02ea 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1234,12 +1234,17 @@ static void
> > samsung_dsim_disable_irq(struct
> > samsung_dsim *dsi)
> > disable_irq(dsi->irq);
> > }
> > -static int samsung_dsim_init(struct samsung_dsim *dsi)
> > +static int samsung_dsim_init(struct samsung_dsim *dsi,
> > unsigned int
> > flag)
> > {
> > const struct samsung_dsim_driver_data *driver_data =
> > dsi->driver_data;
> > +if (dsi->state & flag)
> > +return 0;
> > +
> > samsung_dsim_reset(dsi);
> > -samsung_dsim_enable_irq(dsi);
> > +
> > +if (!(dsi->state & DSIM_STATE_INITIALIZED))
> > +samsung_dsim_enable_irq(dsi);
> > if (driver_data->reg_values[RESET_TYPE] ==
> > DSIM_FUNCRST)
> > samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) -
> > 1);
> > @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> > samsung_dsim *dsi)
> > samsung_dsim_set_phy_ctrl(dsi);
> > samsung_dsim_init_link(dsi);
> > +dsi->state |= flag;
> > +
> > return 0;
> > }
> > @@ -1269,6 +1276,10 @@ static void
> > samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> > }
> > dsi->state |= DSIM_STATE_ENABLED;
> > +
> > +ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>
[PATCH v4 4/7] accel/ivpu: Add IPC driver and JSM messages
The IPC driver is used to send and receive messages to/from firmware
running on the VPU.
The only supported IPC message format is Job Submission Model (JSM)
defined in vpu_jsm_api.h header.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/Makefile | 2 +
drivers/accel/ivpu/ivpu_drv.c | 13 +
drivers/accel/ivpu/ivpu_drv.h | 2 +
drivers/accel/ivpu/ivpu_hw_mtl.c | 4 +
drivers/accel/ivpu/ivpu_ipc.c | 508 +++
drivers/accel/ivpu/ivpu_ipc.h | 93 +++
drivers/accel/ivpu/ivpu_jsm_msg.c | 170 +
drivers/accel/ivpu/ivpu_jsm_msg.h | 23 +
drivers/accel/ivpu/vpu_jsm_api.h | 999 ++
9 files changed, 1814 insertions(+)
create mode 100644 drivers/accel/ivpu/ivpu_ipc.c
create mode 100644 drivers/accel/ivpu/ivpu_ipc.h
create mode 100644 drivers/accel/ivpu/ivpu_jsm_msg.c
create mode 100644 drivers/accel/ivpu/ivpu_jsm_msg.h
create mode 100644 drivers/accel/ivpu/vpu_jsm_api.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 1b4b24ebf5ea..1fe3ad6c2c21 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -5,6 +5,8 @@ intel_vpu-y := \
ivpu_drv.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
+ ivpu_ipc.o \
+ ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 29e78c5ec7c5..6f289e820cd2 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -17,6 +17,7 @@
#include "ivpu_drv.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -230,6 +231,7 @@ int ivpu_shutdown(struct ivpu_device *vdev)
int ret;
ivpu_hw_irq_disable(vdev);
+ ivpu_ipc_disable(vdev);
ivpu_mmu_disable(vdev);
ret = ivpu_hw_power_down(vdev);
@@ -346,6 +348,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->mmu)
return -ENOMEM;
+ vdev->ipc = drmm_kzalloc(>drm, sizeof(*vdev->ipc), GFP_KERNEL);
+ if (!vdev->ipc)
+ return -ENOMEM;
+
vdev->hw->ops = _hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -390,6 +396,12 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_mmu_gctx_fini;
}
+ ret = ivpu_ipc_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize IPC: %d\n", ret);
+ goto err_mmu_gctx_fini;
+ }
+
return 0;
err_mmu_gctx_fini:
@@ -404,6 +416,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_ipc_fini(vdev);
ivpu_mmu_global_context_fini(vdev);
drm_WARN_ON(>drm, !xa_empty(>context_xa));
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 69088a03928a..1b9ac8dd8ae7 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -74,6 +74,7 @@ struct ivpu_wa_table {
struct ivpu_hw_info;
struct ivpu_mmu_info;
+struct ivpu_ipc_info;
struct ivpu_device {
struct drm_device drm;
@@ -85,6 +86,7 @@ struct ivpu_device {
struct ivpu_wa_table wa;
struct ivpu_hw_info *hw;
struct ivpu_mmu_info *mmu;
+ struct ivpu_ipc_info *ipc;
struct ivpu_mmu_context gctx;
struct xarray context_xa;
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c b/drivers/accel/ivpu/ivpu_hw_mtl.c
index 39350203452d..fb2b79daabfc 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_mtl.c
@@ -7,6 +7,7 @@
#include "ivpu_hw_mtl_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#define TILE_FUSE_ENABLE_BOTH 0x0
@@ -934,6 +935,9 @@ static u32 ivpu_hw_mtl_irqv_handler(struct ivpu_device
*vdev, int irq)
if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_0_INT, status))
ivpu_mmu_irq_evtq_handler(vdev);
+ if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, HOST_IPC_FIFO_INT,
status))
+ ivpu_ipc_irq_handler(vdev);
+
if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_1_INT, status))
ivpu_dbg(vdev, IRQ, "MMU sync complete\n");
diff --git a/drivers/accel/ivpu/ivpu_ipc.c b/drivers/accel/ivpu/ivpu_ipc.c
new file mode 100644
index ..4bcf3c827235
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_ipc.c
@@ -0,0 +1,508 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020-2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_hw.h"
[PATCH v4 7/7] accel/ivpu: Add PM support
- Implement cold and warm firmware boot flows
- Add hang recovery support
- Add runtime power management support
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/Makefile | 3 +-
drivers/accel/ivpu/ivpu_drv.c| 28 +++
drivers/accel/ivpu/ivpu_drv.h| 2 +
drivers/accel/ivpu/ivpu_fw.c | 4 +
drivers/accel/ivpu/ivpu_hw_mtl.c | 12 ++
drivers/accel/ivpu/ivpu_ipc.c| 5 +-
drivers/accel/ivpu/ivpu_job.c| 13 +-
drivers/accel/ivpu/ivpu_mmu.c| 12 +-
drivers/accel/ivpu/ivpu_pm.c | 329 +++
drivers/accel/ivpu/ivpu_pm.h | 38
10 files changed, 442 insertions(+), 4 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_pm.c
create mode 100644 drivers/accel/ivpu/ivpu_pm.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 64b3ef5cb37c..ced15ec7d33b 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -10,6 +10,7 @@ intel_vpu-y := \
ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
- ivpu_mmu_context.o
+ ivpu_mmu_context.o \
+ ivpu_pm.o
obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
\ No newline at end of file
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index aebb804df2d4..c380b4d7762c 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -24,6 +24,7 @@
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
+#include "ivpu_pm.h"
#ifndef DRIVER_VERSION_STR
#define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
@@ -469,6 +470,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->ipc)
return -ENOMEM;
+ vdev->pm = drmm_kzalloc(>drm, sizeof(*vdev->pm), GFP_KERNEL);
+ if (!vdev->pm)
+ return -ENOMEM;
+
vdev->hw->ops = _hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -528,6 +533,12 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_fini;
}
+ ret = ivpu_pm_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize PM: %d\n", ret);
+ goto err_ipc_fini;
+ }
+
ret = ivpu_job_done_thread_init(vdev);
if (ret) {
ivpu_err(vdev, "Failed to initialize job done thread: %d\n",
ret);
@@ -546,6 +557,8 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_job_done_thread_fini;
}
+ ivpu_pm_enable(vdev);
+
return 0;
err_job_done_thread_fini:
@@ -566,6 +579,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
+ ivpu_pm_disable(vdev);
ivpu_shutdown(vdev);
ivpu_job_done_thread_fini(vdev);
ivpu_ipc_fini(vdev);
@@ -618,11 +632,25 @@ static void ivpu_remove(struct pci_dev *pdev)
ivpu_dev_fini(vdev);
}
+static const struct dev_pm_ops ivpu_drv_pci_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(ivpu_pm_suspend_cb, ivpu_pm_resume_cb)
+ SET_RUNTIME_PM_OPS(ivpu_pm_runtime_suspend_cb,
ivpu_pm_runtime_resume_cb, NULL)
+};
+
+static const struct pci_error_handlers ivpu_drv_pci_err = {
+ .reset_prepare = ivpu_pm_reset_prepare_cb,
+ .reset_done = ivpu_pm_reset_done_cb,
+};
+
static struct pci_driver ivpu_pci_driver = {
.name = KBUILD_MODNAME,
.id_table = ivpu_pci_ids,
.probe = ivpu_probe,
.remove = ivpu_remove,
+ .driver = {
+ .pm = _drv_pci_pm,
+ },
+ .err_handler = _drv_pci_err,
};
module_pci_driver(ivpu_pci_driver);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 91703b86bfed..38f5e5991594 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -76,6 +76,7 @@ struct ivpu_hw_info;
struct ivpu_mmu_info;
struct ivpu_fw_info;
struct ivpu_ipc_info;
+struct ivpu_pm_info;
struct ivpu_device {
struct drm_device drm;
@@ -89,6 +90,7 @@ struct ivpu_device {
struct ivpu_mmu_info *mmu;
struct ivpu_fw_info *fw;
struct ivpu_ipc_info *ipc;
+ struct ivpu_pm_info *pm;
struct ivpu_mmu_context gctx;
struct xarray context_xa;
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 91bc6b167e58..6afd4c81cf5a 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -14,6 +14,7 @@
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_pm.h"
#define FW_GLOBAL_MEM_START(2ull * SZ_1G)
#define FW_GLOBAL_MEM_END (3ull * SZ_1G)
@@ -361,9 +362,12 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev,
struct vpu_boot_params
/* In case of warm boot we only have to reset the entrypoint addr */
if
[PATCH v4 5/7] accel/ivpu: Implement firmware parsing and booting
Read, parse and boot VPU firmware image.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 131 +-
drivers/accel/ivpu/ivpu_drv.h | 11 +
drivers/accel/ivpu/ivpu_fw.c | 419 ++
drivers/accel/ivpu/ivpu_fw.h | 38 +++
drivers/accel/ivpu/ivpu_hw_mtl.c | 10 +
drivers/accel/ivpu/vpu_boot_api.h | 349 +
include/uapi/drm/ivpu_drm.h | 21 ++
8 files changed, 979 insertions(+), 1 deletion(-)
create mode 100644 drivers/accel/ivpu/ivpu_fw.c
create mode 100644 drivers/accel/ivpu/ivpu_fw.h
create mode 100644 drivers/accel/ivpu/vpu_boot_api.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 1fe3ad6c2c21..c7f64e70261f 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_fw.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 6f289e820cd2..a222700d31a6 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -14,10 +14,13 @@
#include
#include
+#include "vpu_boot_api.h"
#include "ivpu_drv.h"
+#include "ivpu_fw.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -32,6 +35,10 @@ int ivpu_dbg_mask;
module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);
MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros.");
+int ivpu_test_mode;
+module_param_named_unsafe(test_mode, ivpu_test_mode, int, 0644);
+MODULE_PARM_DESC(test_mode, "Test mode: 0 - normal operation, 1 - fw unit
test, 2 - null hw");
+
u8 ivpu_pll_min_ratio;
module_param_named(pll_min_ratio, ivpu_pll_min_ratio, byte, 0644);
MODULE_PARM_DESC(pll_min_ratio, "Minimum PLL ratio used to set VPU frequency");
@@ -129,6 +136,28 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
case DRM_IVPU_PARAM_CONTEXT_ID:
args->value = file_priv->ctx.id;
break;
+ case DRM_IVPU_PARAM_FW_API_VERSION:
+ if (args->index < VPU_FW_API_VER_NUM) {
+ struct vpu_firmware_header *fw_hdr;
+
+ fw_hdr = (struct vpu_firmware_header
*)vdev->fw->file->data;
+ args->value = fw_hdr->api_version[args->index];
+ } else {
+ ret = -EINVAL;
+ }
+ break;
+ case DRM_IVPU_PARAM_ENGINE_HEARTBEAT:
+ ret = ivpu_jsm_get_heartbeat(vdev, args->index, >value);
+ break;
+ case DRM_IVPU_PARAM_UNIQUE_INFERENCE_ID:
+ args->value =
(u64)atomic64_inc_return(>unique_id_counter);
+ break;
+ case DRM_IVPU_PARAM_TILE_CONFIG:
+ args->value = vdev->hw->tile_fuse;
+ break;
+ case DRM_IVPU_PARAM_SKU:
+ args->value = vdev->hw->sku;
+ break;
default:
ret = -EINVAL;
break;
@@ -226,11 +255,85 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl, 0),
};
+static int ivpu_wait_for_ready(struct ivpu_device *vdev)
+{
+ struct ivpu_ipc_consumer cons;
+ struct ivpu_ipc_hdr ipc_hdr;
+ unsigned long timeout;
+ int ret;
+
+ if (ivpu_test_mode == IVPU_TEST_MODE_FW_TEST)
+ return 0;
+
+ ivpu_ipc_consumer_add(vdev, , IVPU_IPC_CHAN_BOOT_MSG);
+
+ timeout = jiffies + msecs_to_jiffies(vdev->timeout.boot);
+ while (1) {
+ ret = ivpu_ipc_irq_handler(vdev);
+ if (ret)
+ break;
+ ret = ivpu_ipc_receive(vdev, , _hdr, NULL, 0);
+ if (ret != -ETIMEDOUT || time_after_eq(jiffies, timeout))
+ break;
+
+ cond_resched();
+ }
+
+ ivpu_ipc_consumer_del(vdev, );
+
+ if (!ret && ipc_hdr.data_addr != IVPU_IPC_BOOT_MSG_DATA_ADDR) {
+ ivpu_err(vdev, "Invalid VPU ready message: 0x%x\n",
+ipc_hdr.data_addr);
+ return -EIO;
+ }
+
+ if (!ret)
+ ivpu_info(vdev, "VPU ready message received successfully\n");
+ else
+ ivpu_hw_diagnose_failure(vdev);
+
+ return ret;
+}
+
+/**
+ * ivpu_boot() - Start VPU firmware
+ * @vdev: VPU device
+ *
+ * This function is paired with ivpu_shutdown() but it doesn't power up the
+ * VPU because power up has to be called very early in ivpu_probe().
+ */
+int ivpu_boot(struct ivpu_device *vdev)
+{
+ int ret;
+
+
[PATCH v4 3/7] accel/ivpu: Add GEM buffer object management
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are relased when the
buffer is destroyed.
Eviction mechism is planned for future versions.
Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 31 +-
drivers/accel/ivpu/ivpu_drv.h | 1 +
drivers/accel/ivpu/ivpu_gem.c | 820 ++
drivers/accel/ivpu/ivpu_gem.h | 128 ++
include/uapi/drm/ivpu_drm.h | 127 ++
6 files changed, 1106 insertions(+), 2 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_gem.c
create mode 100644 drivers/accel/ivpu/ivpu_gem.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 37b8bf1d3247..1b4b24ebf5ea 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index a22d41ca5a4b..29e78c5ec7c5 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -12,8 +12,10 @@
#include
#include
#include
+#include
#include "ivpu_drv.h"
+#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -49,6 +51,24 @@ struct ivpu_file_priv *ivpu_file_priv_get(struct
ivpu_file_priv *file_priv)
return file_priv;
}
+struct ivpu_file_priv *ivpu_file_priv_get_by_ctx_id(struct ivpu_device *vdev,
unsigned long id)
+{
+ struct ivpu_file_priv *file_priv;
+
+ xa_lock_irq(>context_xa);
+ file_priv = xa_load(>context_xa, id);
+ /* file_priv may still be in context_xa during file_priv_release() */
+ if (file_priv && !kref_get_unless_zero(_priv->ref))
+ file_priv = NULL;
+ xa_unlock_irq(>context_xa);
+
+ if (file_priv)
+ ivpu_dbg(vdev, KREF, "file_priv get by id: ctx %u refcount
%u\n",
+file_priv->ctx.id, kref_read(_priv->ref));
+
+ return file_priv;
+}
+
static void file_priv_release(struct kref *ref)
{
struct ivpu_file_priv *file_priv = container_of(ref, struct
ivpu_file_priv, ref);
@@ -57,7 +77,7 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
ivpu_mmu_user_context_fini(vdev, _priv->ctx);
- WARN_ON(xa_erase_irq(>context_xa, file_priv->ctx.id) !=
file_priv);
+ drm_WARN_ON(>drm, xa_erase_irq(>context_xa,
file_priv->ctx.id) != file_priv);
kfree(file_priv);
}
@@ -66,7 +86,7 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link)
struct ivpu_file_priv *file_priv = *link;
struct ivpu_device *vdev = file_priv->vdev;
- WARN_ON(!file_priv);
+ drm_WARN_ON(>drm, !file_priv);
ivpu_dbg(vdev, KREF, "file_priv put: ctx %u refcount %u\n",
file_priv->ctx.id, kref_read(_priv->ref));
@@ -200,6 +220,9 @@ static void ivpu_postclose(struct drm_device *dev, struct
drm_file *file)
static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl, 0),
};
int ivpu_shutdown(struct ivpu_device *vdev)
@@ -233,6 +256,10 @@ static const struct drm_driver driver = {
.open = ivpu_open,
.postclose = ivpu_postclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ivpu_gem_prime_import,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 6e8b88068fc9..69088a03928a 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -114,6 +114,7 @@ extern u8 ivpu_pll_min_ratio;
extern u8 ivpu_pll_max_ratio;
struct ivpu_file_priv *ivpu_file_priv_get(struct ivpu_file_priv *file_priv);
+struct ivpu_file_priv *ivpu_file_priv_get_by_ctx_id(struct ivpu_device *vdev,
unsigned long id);
void ivpu_file_priv_put(struct ivpu_file_priv **link);
int
[PATCH v4 6/7] accel/ivpu: Add command buffer submission logic
Each of the user contexts has two command queues, one for compute engine
and one for the copy engine. Command queues are allocated and registered
in the device when the first job (command buffer) is submitted from
the user space to the VPU device. The userspace provides a list of
GEM buffer object handles to submit to the VPU, the driver resolves
buffer handles, pins physical memory if needed, increments ref count
for each buffer and stores pointers to buffer objects in
the ivpu_job objects that track jobs submitted to the device.
The VPU signals job completion with an asynchronous message that
contains the job id passed to firmware when the job was submitted.
Currently, the driver supports simple scheduling logic
where jobs submitted from user space are immediately pushed
to the VPU device command queues. In the future, it will be
extended to use hardware base scheduling and/or drm_sched.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 34 +-
drivers/accel/ivpu/ivpu_drv.h | 5 +
drivers/accel/ivpu/ivpu_gem.c | 26 ++
drivers/accel/ivpu/ivpu_gem.h | 1 +
drivers/accel/ivpu/ivpu_job.c | 597 ++
drivers/accel/ivpu/ivpu_job.h | 67
include/uapi/drm/ivpu_drm.h | 92 ++
8 files changed, 819 insertions(+), 4 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_job.c
create mode 100644 drivers/accel/ivpu/ivpu_job.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index c7f64e70261f..64b3ef5cb37c 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -7,6 +7,7 @@ intel_vpu-y := \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
+ ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index a222700d31a6..aebb804df2d4 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -20,6 +20,7 @@
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_job.h"
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -31,6 +32,8 @@
static const struct drm_driver driver;
+static struct lock_class_key submitted_jobs_xa_lock_class_key;
+
int ivpu_dbg_mask;
module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);
MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros.");
@@ -84,8 +87,11 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
+ ivpu_cmdq_release_all(file_priv);
+ ivpu_bo_remove_all_bos_from_context(_priv->ctx);
ivpu_mmu_user_context_fini(vdev, _priv->ctx);
drm_WARN_ON(>drm, xa_erase_irq(>context_xa,
file_priv->ctx.id) != file_priv);
+ mutex_destroy(_priv->lock);
kfree(file_priv);
}
@@ -209,10 +215,11 @@ static int ivpu_open(struct drm_device *dev, struct
drm_file *file)
file_priv->vdev = vdev;
file_priv->priority = DRM_IVPU_CONTEXT_PRIORITY_NORMAL;
kref_init(_priv->ref);
+ mutex_init(_priv->lock);
ret = ivpu_mmu_user_context_init(vdev, _priv->ctx, ctx_id);
if (ret)
- goto err_free_file_priv;
+ goto err_mutex_destroy;
old = xa_store_irq(>context_xa, ctx_id, file_priv, GFP_KERNEL);
if (xa_is_err(old)) {
@@ -229,7 +236,8 @@ static int ivpu_open(struct drm_device *dev, struct
drm_file *file)
err_ctx_fini:
ivpu_mmu_user_context_fini(vdev, _priv->ctx);
-err_free_file_priv:
+err_mutex_destroy:
+ mutex_destroy(_priv->lock);
kfree(file_priv);
err_xa_erase:
xa_erase_irq(>context_xa, ctx_id);
@@ -253,6 +261,8 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_SUBMIT, ivpu_submit_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_WAIT, ivpu_bo_wait_ioctl, 0),
};
static int ivpu_wait_for_ready(struct ivpu_device *vdev)
@@ -465,6 +475,8 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
vdev->context_xa_limit.max = IVPU_CONTEXT_LIMIT;
atomic64_set(>unique_id_counter, 0);
xa_init_flags(>context_xa, XA_FLAGS_ALLOC);
+ xa_init_flags(>submitted_jobs_xa, XA_FLAGS_ALLOC1);
+ lockdep_set_class(>submitted_jobs_xa.xa_lock,
_jobs_xa_lock_class_key);
ret = ivpu_pci_init(vdev);
if (ret) {
@@ -516,20 +528,30 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_fini;
}
+ ret = ivpu_job_done_thread_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize job done thread:
[PATCH v4 1/7] accel/ivpu: Introduce a new DRM driver for Intel VPU
/* Power up early so the rest of init code can access VPU registers */
+ ret = ivpu_hw_power_up(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to power up HW: %d\n", ret);
+ goto err_xa_destroy;
+ }
+
+ return 0;
+
+err_xa_destroy:
+ xa_destroy(>context_xa);
+ return ret;
+}
+
+static void ivpu_dev_fini(struct ivpu_device *vdev)
+{
+ ivpu_shutdown(vdev);
+
+ drm_WARN_ON(>drm, !xa_empty(>context_xa));
+ xa_destroy(>context_xa);
+}
+
+static struct pci_device_id ivpu_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, ivpu_pci_ids);
+
+static int ivpu_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ struct ivpu_device *vdev;
+ int ret;
+
+ vdev = devm_drm_dev_alloc(>dev, , struct ivpu_device, drm);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ pci_set_drvdata(pdev, vdev);
+
+ ret = ivpu_dev_init(vdev);
+ if (ret) {
+ dev_err(>dev, "Failed to initialize VPU device: %d\n",
ret);
+ return ret;
+ }
+
+ ret = drm_dev_register(>drm, 0);
+ if (ret) {
+ dev_err(>dev, "Failed to register DRM device: %d\n", ret);
+ ivpu_dev_fini(vdev);
+ }
+
+ return ret;
+}
+
+static void ivpu_remove(struct pci_dev *pdev)
+{
+ struct ivpu_device *vdev = pci_get_drvdata(pdev);
+
+ drm_dev_unregister(>drm);
+ ivpu_dev_fini(vdev);
+}
+
+static struct pci_driver ivpu_pci_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = ivpu_pci_ids,
+ .probe = ivpu_probe,
+ .remove = ivpu_remove,
+};
+
+module_pci_driver(ivpu_pci_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL and additional rights");
+MODULE_VERSION(DRIVER_VERSION_STR);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
new file mode 100644
index ..4f859e7ac09e
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -0,0 +1,162 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020-2022 Intel Corporation
+ */
+
+#ifndef __IVPU_DRV_H__
+#define __IVPU_DRV_H__
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define DRIVER_NAME "intel_vpu"
+#define DRIVER_DESC "Driver for Intel Versatile Processing Unit (VPU)"
+#define DRIVER_DATE "20221208"
+
+#define PCI_DEVICE_ID_MTL 0x7d1d
+
+#define IVPU_GLOBAL_CONTEXT_MMU_SSID 0
+#define IVPU_CONTEXT_LIMIT 64
+#define IVPU_NUM_ENGINES2
+
+#define IVPU_PLATFORM_SILICON 0
+#define IVPU_PLATFORM_SIMICS 2
+#define IVPU_PLATFORM_FPGA3
+#define IVPU_PLATFORM_INVALID 8
+
+#define IVPU_DBG_REGBIT(0)
+#define IVPU_DBG_IRQBIT(1)
+#define IVPU_DBG_MMUBIT(2)
+#define IVPU_DBG_FILE BIT(3)
+#define IVPU_DBG_MISC BIT(4)
+#define IVPU_DBG_FW_BOOT BIT(5)
+#define IVPU_DBG_PM BIT(6)
+#define IVPU_DBG_IPCBIT(7)
+#define IVPU_DBG_BO BIT(8)
+#define IVPU_DBG_JOBBIT(9)
+#define IVPU_DBG_JSMBIT(10)
+#define IVPU_DBG_KREF BIT(11)
+#define IVPU_DBG_RPMBIT(12)
+
+#define ivpu_err(vdev, fmt, ...) \
+ drm_err(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_err_ratelimited(vdev, fmt, ...) \
+ drm_err_ratelimited(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_warn(vdev, fmt, ...) \
+ drm_warn(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_warn_ratelimited(vdev, fmt, ...) \
+ drm_err_ratelimited(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_info(vdev, fmt, ...) drm_info(&(vdev)->drm, fmt, ##__VA_ARGS__)
+
+#define ivpu_dbg(vdev, type, fmt, args...) do {
\
+ if (unlikely(IVPU_DBG_##type & ivpu_dbg_mask)) \
+ dev_dbg((vdev)->drm.dev, "[%s] " fmt, #type, ##args); \
+} while (0)
+
+#define IVPU_WA(wa_name) (vdev->wa.wa_name)
+
+struct ivpu_wa_table {
+ bool punit_disabled;
+ bool clear_runtime_mem;
+};
+
+struct ivpu_hw_info;
+
+struct ivpu_device {
+ struct drm_device drm;
+ void __iomem *regb;
+ void __iomem *regv;
+ u32 platform;
+ u32 irq;
+
+ struct ivpu_wa_table wa;
+ struct ivpu_hw_info *hw;
+
+ struct xarray context_xa;
+ struct xa_limit context_xa_limit;
+
+ struct {
+ int boot;
+ int jsm;
+ int tdr;
+ int reschedule_suspend;
+ } timeout;
+};
+
+/*
+ * file_priv has its own refcount (ref) that allows user space to close the fd
+ * without blocking even if VPU is still processing some jobs.
+ */
+struct
[PATCH v4 2/7] accel/ivpu: Add Intel VPU MMU support
iv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
- if (!file_priv)
- return -ENOMEM;
+ if (!file_priv) {
+ ret = -ENOMEM;
+ goto err_xa_erase;
+ }
file_priv->vdev = vdev;
file_priv->priority = DRM_IVPU_CONTEXT_PRIORITY_NORMAL;
kref_init(_priv->ref);
+ ret = ivpu_mmu_user_context_init(vdev, _priv->ctx, ctx_id);
+ if (ret)
+ goto err_free_file_priv;
+
+ old = xa_store_irq(>context_xa, ctx_id, file_priv, GFP_KERNEL);
+ if (xa_is_err(old)) {
+ ret = xa_err(old);
+ ivpu_err(vdev, "Failed to store context %u: %d\n", ctx_id, ret);
+ goto err_ctx_fini;
+ }
+
+ ivpu_dbg(vdev, FILE, "file_priv create: ctx %u process %s pid %d\n",
+ctx_id, current->comm, task_pid_nr(current));
+
file->driver_priv = file_priv;
return 0;
+
+err_ctx_fini:
+ ivpu_mmu_user_context_fini(vdev, _priv->ctx);
+err_free_file_priv:
+ kfree(file_priv);
+err_xa_erase:
+ xa_erase_irq(>context_xa, ctx_id);
+ return ret;
}
static void ivpu_postclose(struct drm_device *dev, struct drm_file *file)
{
struct ivpu_file_priv *file_priv = file->driver_priv;
+ struct ivpu_device *vdev = to_ivpu_device(dev);
+
+ ivpu_dbg(vdev, FILE, "file_priv close: ctx %u process %s pid %d\n",
+file_priv->ctx.id, current->comm, task_pid_nr(current));
ivpu_file_priv_put(_priv);
}
@@ -150,6 +207,7 @@ int ivpu_shutdown(struct ivpu_device *vdev)
int ret;
ivpu_hw_irq_disable(vdev);
+ ivpu_mmu_disable(vdev);
ret = ivpu_hw_power_down(vdev);
if (ret)
@@ -257,6 +315,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->hw)
return -ENOMEM;
+ vdev->mmu = drmm_kzalloc(>drm, sizeof(*vdev->mmu), GFP_KERNEL);
+ if (!vdev->mmu)
+ return -ENOMEM;
+
vdev->hw->ops = _hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -289,8 +351,24 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_xa_destroy;
}
+ ret = ivpu_mmu_global_context_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize global MMU context: %d\n",
ret);
+ goto err_power_down;
+ }
+
+ ret = ivpu_mmu_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize MMU device: %d\n", ret);
+ goto err_mmu_gctx_fini;
+ }
+
return 0;
+err_mmu_gctx_fini:
+ ivpu_mmu_global_context_fini(vdev);
+err_power_down:
+ ivpu_hw_power_down(vdev);
err_xa_destroy:
xa_destroy(>context_xa);
return ret;
@@ -299,6 +377,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_mmu_global_context_fini(vdev);
drm_WARN_ON(>drm, !xa_empty(>context_xa));
xa_destroy(>context_xa);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 4f859e7ac09e..6e8b88068fc9 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -15,6 +15,8 @@
#include
#include
+#include "ivpu_mmu_context.h"
+
#define DRIVER_NAME "intel_vpu"
#define DRIVER_DESC "Driver for Intel Versatile Processing Unit (VPU)"
#define DRIVER_DATE "20221208"
@@ -71,6 +73,7 @@ struct ivpu_wa_table {
};
struct ivpu_hw_info;
+struct ivpu_mmu_info;
struct ivpu_device {
struct drm_device drm;
@@ -81,7 +84,9 @@ struct ivpu_device {
struct ivpu_wa_table wa;
struct ivpu_hw_info *hw;
+ struct ivpu_mmu_info *mmu;
+ struct ivpu_mmu_context gctx;
struct xarray context_xa;
struct xa_limit context_xa_limit;
@@ -100,6 +105,7 @@ struct ivpu_device {
struct ivpu_file_priv {
struct kref ref;
struct ivpu_device *vdev;
+ struct ivpu_mmu_context ctx;
u32 priority;
};
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c b/drivers/accel/ivpu/ivpu_hw_mtl.c
index c84bacd4d0f5..39350203452d 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_mtl.c
@@ -7,6 +7,7 @@
#include "ivpu_hw_mtl_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
#define TILE_FUSE_ENABLE_BOTH 0x0
#define TILE_FUSE_ENABLE_UPPER 0x1
@@ -930,6 +931,15 @@ static u32 ivpu_hw_mtl_irqv_handler(struct ivpu_device
*vdev, int irq)
REGV_WR32(MTL_VPU_HOST_SS_ICB_CLEAR_0, status);
+ if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_0_INT, status))
+ ivpu_mmu_irq_evtq_han
[PATCH v4 0/7] New DRM accel driver for Intel VPU
Hi, This patchset contains a new Linux* Kernel Driver for Intel® VPUs. VPU stands for Versatile Processing Unit and it is an AI inference accelerator integrated with Intel non-server CPUs starting from 14th generation. VPU enables efficient execution of Deep Learning applications like object detection, classification etc. The whole driver is licensed under GPL-2.0-only except for two headers imported from the firmware that are MIT licensed. User mode driver stack consists of Level Zero API driver and OpenVINO plugin. Both should be open-sourced in December. The firmware for the VPU will be distributed as a closed source binary. Most significant change in this version is a switch to the new accel framework. Besides that there are a lot of changes from v3 review described in detail below. Regards, Jacek Changelog v4: - Switch to the accel framework (DRIVER_COMPUTE_ACCEL) - Move the driver from drivers/gpu/drm to drivers/accel - Rename kconfig DRM_IVPU option to DRM_ACCEL_IVPU and update dependencies - Create context on open() instead of lazy allocating it - Remove status_offset from submit ioctl, as status is now reported in bo_wait ioctl - Use managed resources in ivpu_drv.c - Optimize locking in ivpu_ipc.c - add new rx_msg_lock for consumer msg list - Refactor vpu_hw_mtl_reg.h to use BIT_MASK() and GENMASK() macros - Use module_pci_driver() for mudule init - Remove mutex from "struct ivpu_pm_info" - Add explicit "vdev" arg to ivpu_dbg() - Use drm_WARN_ON() instead of WARN_ON() where possible - Add comments for boot related functions - Update firmware API headers v3: https://lore.kernel.org/all/20220924151149.323622-1-jacek.lawrynow...@linux.intel.com/ - Fixed alignment warning in ivpu_ipc.c when building with W=1 v2: https://lore.kernel.org/all/20220913121017.993825-1-jacek.lawrynow...@linux.intel.com/ - Rename the driver from "drm/vpu" to "drm/ivpu" - Add a TODO file - Add support for WC buffers v1: https://lore.kernel.org/all/20220728131709.1087188-1-jacek.lawrynow...@linux.intel.com/ Jacek Lawrynowicz (7): accel/ivpu: Introduce a new DRM driver for Intel VPU accel/ivpu: Add Intel VPU MMU support accel/ivpu: Add GEM buffer object management accel/ivpu: Add IPC driver and JSM messages accel/ivpu: Implement firmware parsing and booting accel/ivpu: Add command buffer submission logic accel/ivpu: Add PM support MAINTAINERS |9 + drivers/Makefile |1 + drivers/accel/Kconfig |2 + drivers/accel/Makefile|3 + drivers/accel/ivpu/Kconfig| 15 + drivers/accel/ivpu/Makefile | 16 + drivers/accel/ivpu/TODO |7 + drivers/accel/ivpu/ivpu_drv.c | 661 +++ drivers/accel/ivpu/ivpu_drv.h | 189 + drivers/accel/ivpu/ivpu_fw.c | 423 ++ drivers/accel/ivpu/ivpu_fw.h | 38 + drivers/accel/ivpu/ivpu_gem.c | 846 +++ drivers/accel/ivpu/ivpu_gem.h | 129 +++ drivers/accel/ivpu/ivpu_hw.h | 170 drivers/accel/ivpu/ivpu_hw_mtl.c | 1084 + drivers/accel/ivpu/ivpu_hw_mtl_reg.h | 280 +++ drivers/accel/ivpu/ivpu_hw_reg_io.h | 115 +++ drivers/accel/ivpu/ivpu_ipc.c | 511 drivers/accel/ivpu/ivpu_ipc.h | 93 +++ drivers/accel/ivpu/ivpu_job.c | 608 ++ drivers/accel/ivpu/ivpu_job.h | 67 ++ drivers/accel/ivpu/ivpu_jsm_msg.c | 170 drivers/accel/ivpu/ivpu_jsm_msg.h | 23 + drivers/accel/ivpu/ivpu_mmu.c | 885 drivers/accel/ivpu/ivpu_mmu.h | 50 ++ drivers/accel/ivpu/ivpu_mmu_context.c | 385 + drivers/accel/ivpu/ivpu_mmu_context.h | 49 ++ drivers/accel/ivpu/ivpu_pm.c | 329 drivers/accel/ivpu/ivpu_pm.h | 38 + drivers/accel/ivpu/vpu_boot_api.h | 349 drivers/accel/ivpu/vpu_jsm_api.h | 999 +++ include/uapi/drm/ivpu_drm.h | 339 32 files changed, 8883 insertions(+) create mode 100644 drivers/accel/Makefile create mode 100644 drivers/accel/ivpu/Kconfig create mode 100644 drivers/accel/ivpu/Makefile create mode 100644 drivers/accel/ivpu/TODO create mode 100644 drivers/accel/ivpu/ivpu_drv.c create mode 100644 drivers/accel/ivpu/ivpu_drv.h create mode 100644 drivers/accel/ivpu/ivpu_fw.c create mode 100644 drivers/accel/ivpu/ivpu_fw.h create mode 100644 drivers/accel/ivpu/ivpu_gem.c create mode 100644 drivers/accel/ivpu/ivpu_gem.h create mode 100644 drivers/accel/ivpu/ivpu_hw.h create mode 100644 drivers/accel/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/accel/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/accel/ivpu/ivpu_hw_reg_io.h create mode 100644 drivers/accel/ivpu/ivpu_ipc.c create mode 100644 drivers/accel/ivpu/ivpu_ipc.h create mode 100644 drivers/accel/ivpu/ivpu_job.c create mode
Re: [PATCH] drm/vc4: Improve the KUnit documentation
On 12/8/22 06:47, Maxime Ripard wrote: > The command-line can be expressed using a code-block, and we were > missing which architectures were available. > > Suggested-by: Maíra Canal > Signed-off-by: Maxime Ripard > --- Reviewed-by: Maíra Canal Best Regards, - Maíra Canal > Documentation/gpu/vc4.rst | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst > index a2375f1584e6..5e5e92e40919 100644 > --- a/Documentation/gpu/vc4.rst > +++ b/Documentation/gpu/vc4.rst > @@ -61,8 +61,11 @@ The VC4 Driver uses KUnit to perform driver-specific unit > and > integration tests. > > These tests are using a mock driver and can be ran using the > -command:: > - ./tools/testing/kunit/kunit.py run \ > +command below, on either arm or arm64 architectures, > + > +.. code-block:: bash > + > + $ ./tools/testing/kunit/kunit.py run \ > --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \ > --cross_compile aarch64-linux-gnu- --arch arm64 >
Re: [PATCH v2 1/1] dt-bindings: lcdif: Fix constraints for imx8mp
On 08/12/2022 10:45, Alexander Stein wrote:
> i.MX8MP uses 3 clocks, so soften the restrictions for clocks & clock-names.
> This SoC requires a power-domain for this peripheral to use. Add it as
> a required property.
>
> Fixes: f5419cb0743f ("dt-bindings: lcdif: Add compatible for i.MX8MP")
> Signed-off-by: Alexander Stein
> ---
> Changes in v2:
> * Squash both patches into one
> * Split the conditionals from fsl,imx6sx-lcdif
> * Mark power-domains as required for fsl,imx8mp-lcdif
> * Ignored the A-b & R-b due to reorganization
>
> I'm not sure if this is the best way to add the constraints. I noticed that
> imx6sx also uses a power-domain, but imx6ul which is compatible to imx6sx does
> not, so they can't be merged.
>
> I also have noticed that dtbs_check doesn't raise a warning when
> power-domains is actually missing.
>
> .../bindings/display/fsl,lcdif.yaml | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 876015a44a1e6..24014651f7dc8 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -52,6 +52,9 @@ properties:
>interrupts:
> maxItems: 1
>
> + power-domains:
> +maxItems: 1
> +
>port:
> $ref: /schemas/graph.yaml#/properties/port
> description: The LCDIF output port
> @@ -81,7 +84,33 @@ allOf:
>maxItems: 3
>required:
> - clock-names
> -else:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: fsl,imx8mp-lcdif
> +then:
> + properties:
> +clocks:
> + minItems: 3
> + maxItems: 3
> +clock-names:
> + minItems: 3
> + maxItems: 3
> +power-domains:
> + minItems: 1
Drop power domains here.
> + required:
> +- clock-names
> +- power-domains
> + - if:
> + not:
> +properties:
> + compatible:
> +contains:
> + enum:
> +- fsl,imx6sx-lcdif
> +- fsl,imx8mp-lcdif
> +then:
>properties:
> clocks:
>maxItems: 1
Best regards,
Krzysztof
[PATCH] drm/vc4: Improve the KUnit documentation
The command-line can be expressed using a code-block, and we were missing which architectures were available. Suggested-by: Maíra Canal Signed-off-by: Maxime Ripard --- Documentation/gpu/vc4.rst | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst index a2375f1584e6..5e5e92e40919 100644 --- a/Documentation/gpu/vc4.rst +++ b/Documentation/gpu/vc4.rst @@ -61,8 +61,11 @@ The VC4 Driver uses KUnit to perform driver-specific unit and integration tests. These tests are using a mock driver and can be ran using the -command:: - ./tools/testing/kunit/kunit.py run \ +command below, on either arm or arm64 architectures, + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run \ --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \ --cross_compile aarch64-linux-gnu- --arch arm64 -- 2.38.1
[PATCH v2 1/1] dt-bindings: lcdif: Fix constraints for imx8mp
i.MX8MP uses 3 clocks, so soften the restrictions for clocks & clock-names.
This SoC requires a power-domain for this peripheral to use. Add it as
a required property.
Fixes: f5419cb0743f ("dt-bindings: lcdif: Add compatible for i.MX8MP")
Signed-off-by: Alexander Stein
---
Changes in v2:
* Squash both patches into one
* Split the conditionals from fsl,imx6sx-lcdif
* Mark power-domains as required for fsl,imx8mp-lcdif
* Ignored the A-b & R-b due to reorganization
I'm not sure if this is the best way to add the constraints. I noticed that
imx6sx also uses a power-domain, but imx6ul which is compatible to imx6sx does
not, so they can't be merged.
I also have noticed that dtbs_check doesn't raise a warning when
power-domains is actually missing.
.../bindings/display/fsl,lcdif.yaml | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 876015a44a1e6..24014651f7dc8 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -52,6 +52,9 @@ properties:
interrupts:
maxItems: 1
+ power-domains:
+maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: The LCDIF output port
@@ -81,7 +84,33 @@ allOf:
maxItems: 3
required:
- clock-names
-else:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8mp-lcdif
+then:
+ properties:
+clocks:
+ minItems: 3
+ maxItems: 3
+clock-names:
+ minItems: 3
+ maxItems: 3
+power-domains:
+ minItems: 1
+ required:
+- clock-names
+- power-domains
+ - if:
+ not:
+properties:
+ compatible:
+contains:
+ enum:
+- fsl,imx6sx-lcdif
+- fsl,imx8mp-lcdif
+then:
properties:
clocks:
maxItems: 1
--
2.34.1
Re: [Intel-gfx] [PATCH v11 1/1] drm/i915/pxp: Promote pxp subsystem to top-level of i915
Just some small comments and questions below. On 08/12/2022 05:01, Alan Previn wrote: Starting with MTL, there will be two GT-tiles, a render and media tile. PXP as a service for supporting workloads with protected contexts and protected buffers can be subscribed by process workloads on any tile. However, depending on the platform, only one of the tiles is used for control events pertaining to PXP operation (such as creating the arbitration session and session tear-down). PXP as a global feature is accessible via batch buffer instructions on any engine/tile and the coherency across tiles is handled implicitly by the HW. In fact, for the foreseeable future, we are expecting this single-control-tile for the PXP subsystem. In MTL, it's the standalone media tile (not the root tile) because it contains the VDBOX and KCR engine (among the assets PXP relies on for those events). Looking at the current code design, each tile is represented by the intel_gt structure while the intel_pxp structure currently hangs off the intel_gt structure. Keeping the intel_pxp structure within the intel_gt structure makes some internal functionalities more straight forward but adds code complexity to code readibility and maintainibility to many external-to-pxp subsystems readability and maintainability which may need to pick the correct intel_gt structure. An example of this would be the intel_pxp_is_active or intel_pxp_is_enabled functionality which should be viewed as a global level inquiry, not a per-gt inquiry. That said, this series promotes the intel_pxp structure into the drm_i915_private structure making it a top-level subsystem and the PXP subsystem will select the control gt internally and keep a pointer to it for internal reference. This promotion comes with two noteworthy changes: 1. Exported pxp functions that are called by external subsystems (such as intel_pxp_enabled/active) will have to check implicitly if i915->pxp is valid as that structure will not be allocated for HW that doesn't support PXP. 2. Since GT is now considered a soft-dependency of PXP we are ensuring that GT init happens before PXP init and vice versa for fini. This causes a minor ordering change whereby we previously called intel_pxp_suspend after intel_uc_suspend but now is before i915_gem_suspend_late but the change is required for correct dependency flows. Additionally, this re-order change doesn't have any impact because at that point in either case, the top level entry to i915 won't observe any PXP events (since the GPU was quiesced during suspend_prepare). Also, any PXP event doesn't really matter when we disable the PXP HW (global GT irqs are already off anyway, so even if there was a bug that generated spurious events we wouldn't see it and we would just clean it up on resume which is okay since the default fallback action for PXP would be to keep the sessions off at this suspend stage). Changes from prior revs: v10: - Change the code flow for intel_pxp_init to make it more cleaner and readible with better comments explaining the difference between full-PXP-feature vs the partial-teelink inits depending on the platform. Additionally, only do the pxp allocation when we are certain the subsystem is needed. (Tvrtko). v9: - Cosmetic cleanups in supported/enabled/active. (Daniele). - Add comments for intel_pxp_init and pxp_get_ctrl_gt that explain the functional flow for when PXP is not supported but the backend-assets are needed for HuC authentication (Daniele and Tvrtko). - Fix two remaining functions that are accessible outside PXP that need to be checking pxp ptrs before using them: intel_pxp_irq_handler and intel_pxp_huc_load_and_auth (Tvrtko and Daniele). - User helper macro in pxp-debugfs (Tvrtko). v8: - Remove pxp_to_gt macro (Daniele). - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't support GSC-FW on it. (Daniele). - Leave i915->pxp as NULL if we dont support PXP and in line with that, do additional validity check on i915->pxp for intel_pxp_is_supported/enabled/active (Daniele). - Remove unncessary include header from intel_gt_debugfs.c and check drm_minor i915->drm.primary (Daniele). - Other cosmetics / minor issues / more comments on suspend flow order change (Daniele). v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp' through out instead of local variable newpxp. (Rodrigo) - In the case intel_pxp_fini is called during driver unload but after i915 loading failed without pxp being allocated, check i915->pxp before referencing it. (Alan) v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported because : [1] introduction of 'ctrl_gt'
Re: [PATCH v4 0/6] DSI host and peripheral initialisation ordering
On Mon, 5 Dec 2022 17:33:22 +, Dave Stevenson wrote: > Changes from v3 > - Add patch to remove use of drm_bridge_chain from the MTK DP driver, copying > the > same pattern as Sam used for ps8640. > - Add comment for why we update the bridge pointer in > drm_atomic_bridge_chain_post_disable > - Add Frieder's tags > > Changes from v2 (sorry it's taken me a while to get around to these): > - Added Sam's patches to drop drm_bridge_chain functions > - Renamed upstream to previously (Sam) > - Moved copying of panel->prepare_prev_first to bridge->pre_enable_prev_first > from drm_panel_bridge_add_typed to devm_drm_panel_bridge_add_typed (Jagan) > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH v3 00/20] drm: Introduce Kunit Tests to VC4
On Thu, 01 Dec 2022 16:11:31 +0100, Maxime Ripard wrote: > This series introduce Kunit tests to the vc4 KMS driver, but unlike what we > have been doing so far in KMS, it actually tests the atomic modesetting code. > > In order to do so, I've had to improve a fair bit on the Kunit helpers already > found in the tree in order to register a full blown and somewhat functional > KMS > driver. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH 2/2] dt-bindings: lcdif: Add optional power-domain
On 08/12/2022 09:50, Alexander Stein wrote: > Hello Krzysztof, > > Am Donnerstag, 8. Dezember 2022, 09:25:31 CET schrieb Krzysztof Kozlowski: >> On 08/12/2022 06:59, Alexander Stein wrote: >>> Am Mittwoch, 7. Dezember 2022, 17:00:22 CET schrieb Marek Vasut: On 12/7/22 16:14, Alexander Stein wrote: > i.MX8MP requires a power-domain for this peripheral to use. Add it as > an optional property. > > Signed-off-by: Alexander Stein > --- > > Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index > 793e8eccf8b8b..9d9fb5ad587c2 100644 > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > > @@ -52,6 +52,9 @@ properties: > interrupts: > maxItems: 1 > > + power-domains: > +maxItems: 1 > + > > port: > $ref: /schemas/graph.yaml#/properties/port > description: The LCDIF output port Should this be required on mx8mp then ? >>> >>> I'm hesitating to add a required property later on. But I'm okay with >>> both. >>> Rob, Krzysztof: Any preference here? Shall power-domains be made required >>> for fsl,imx8mp-lcdif only? >> >> I don't know. That's not the question to us, but to someone who knows >> the hardware/datasheet. > > I was not talking about the hardware, which needs the power-domain, but the > DT > schema. Sorry to be not specific about this. > Is it okay to add a required property for a compatible later on? Yes, it is okay, assuming: 1. Linux implementation still works without it thus preserving ABI. 2. It is really required, e.g. device cannot operate without it (your commit msg suggests that). 3. The property should be required since beginning, but we did not add it due to mistake/forgot/lack of docs etc. Best regards, Krzysztof
Re: [PATCH 2/2] dt-bindings: lcdif: Add optional power-domain
Hello Krzysztof, Am Donnerstag, 8. Dezember 2022, 09:25:31 CET schrieb Krzysztof Kozlowski: > On 08/12/2022 06:59, Alexander Stein wrote: > > Am Mittwoch, 7. Dezember 2022, 17:00:22 CET schrieb Marek Vasut: > >> On 12/7/22 16:14, Alexander Stein wrote: > >>> i.MX8MP requires a power-domain for this peripheral to use. Add it as > >>> an optional property. > >>> > >>> Signed-off-by: Alexander Stein > >>> --- > >>> > >>> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 3 +++ > >>> 1 file changed, 3 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > >>> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index > >>> 793e8eccf8b8b..9d9fb5ad587c2 100644 > >>> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > >>> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > >>> > >>> @@ -52,6 +52,9 @@ properties: > >>> interrupts: > >>> maxItems: 1 > >>> > >>> + power-domains: > >>> +maxItems: 1 > >>> + > >>> > >>> port: > >>> $ref: /schemas/graph.yaml#/properties/port > >>> description: The LCDIF output port > >> > >> Should this be required on mx8mp then ? > > > > I'm hesitating to add a required property later on. But I'm okay with > > both. > > Rob, Krzysztof: Any preference here? Shall power-domains be made required > > for fsl,imx8mp-lcdif only? > > I don't know. That's not the question to us, but to someone who knows > the hardware/datasheet. I was not talking about the hardware, which needs the power-domain, but the DT schema. Sorry to be not specific about this. Is it okay to add a required property for a compatible later on? Best regards, Alexander
[PULL] drm-misc-next-fixes
Hi, Here's this week drm-misc-next-fixes PR All of those patches seems to have been applied to both drm-misc-next and drm-misc-next-fixes and were part of the final drm-misc-next PR for 6.2. So we shouldn't have any new patch per se, but it aligns all our branches and fixes this odd situation. Maxime drm-misc-next-fixes-2022-12-08: Some deferred-io and damage worker reworks revert and make a fb function static The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6: Merge tag 'drm-intel-next-2022-11-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2022-12-08 for you to fetch changes up to b02897e56b4e1fa6445be695ce5d605bb098435c: Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper" (2022-11-23 09:11:32 +0100) Some deferred-io and damage worker reworks revert and make a fb function static Thomas Zimmermann (6): Merge drm/drm-next into drm-misc-next-fixes Merge drm/drm-next into drm-misc-next-fixes fbdev: Make fb_modesetting_disabled() static inline Revert "drm/fb-helper: Remove damage worker" Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer" Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper" drivers/gpu/drm/drm_fb_helper.c | 30 +- drivers/video/fbdev/core/fb_defio.c | 16 include/drm/drm_fb_helper.h | 2 ++ include/linux/fb.h | 3 +-- 4 files changed, 16 insertions(+), 35 deletions(-) signature.asc Description: PGP signature
Re: [PATCH 2/2] dt-bindings: lcdif: Add optional power-domain
On 08/12/2022 06:59, Alexander Stein wrote: > Am Mittwoch, 7. Dezember 2022, 17:00:22 CET schrieb Marek Vasut: >> On 12/7/22 16:14, Alexander Stein wrote: >>> i.MX8MP requires a power-domain for this peripheral to use. Add it as >>> an optional property. >>> >>> Signed-off-by: Alexander Stein >>> --- >>> >>> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index >>> 793e8eccf8b8b..9d9fb5ad587c2 100644 >>> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>> >>> @@ -52,6 +52,9 @@ properties: >>> interrupts: >>> maxItems: 1 >>> >>> + power-domains: >>> +maxItems: 1 >>> + >>> >>> port: >>> $ref: /schemas/graph.yaml#/properties/port >>> description: The LCDIF output port >> >> Should this be required on mx8mp then ? > > I'm hesitating to add a required property later on. But I'm okay with both. > Rob, Krzysztof: Any preference here? Shall power-domains be made required for > fsl,imx8mp-lcdif only? I don't know. That's not the question to us, but to someone who knows the hardware/datasheet. Best regards, Krzysztof
Re: [PATCH] drm/gud: Fix missing include
Hi
Am 07.12.22 um 20:51 schrieb Noralf Trønnes via B4 Submission Endpoint:
From: Noralf Trønnes
Add missing vmalloc.h include.
Fixes: c17d048609bf ("drm/gud: Use the shadow plane helper")
Reported-by: kernel test robot
Signed-off-by: Noralf Trønnes
Reviewed-by: Thomas Zimmermann
The missing-vmalloc() error is a real classic. :( Some architectures
declare the function and some don't.
Best regards
Thomas
---
drivers/gpu/drm/gud/gud_pipe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index 62c43d3632d4..dc16a92625d4 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
---
base-commit: 5ad8e63ebba3d5a0730b43180b200e41eeb9409c
change-id: 20221207-gud-missing-include-9ccf56382f8a
Best regards,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
