[PATCH] drm/armada: Fix a potential double free in armada_drm_bind
priv is a managed resource allocated with devm_drm_dev_alloc(), so there
is no need to call kfree() explicitly or there will be a double
free.
Fixes: 90ad200b4cbc ("drm/armada: Use devm_drm_dev_alloc")
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/armada/armada_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 0643887800b4..142668cd6d7c 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -99,7 +99,6 @@ static int armada_drm_bind(struct device *dev)
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
- kfree(priv);
return ret;
}
--
2.17.1
Re: [PATCH] drm/mipi-dbi: Fix max_chunk calculation in spi_transfer
Den 08.03.2022 02.56, skrev Yunhao Tian:
> In __spi_validate, there's a validation that no partial transfers
> are accepted (xfer->len % w_size must be zero). When
> max_chunk is not a multiple of bpw (e.g.max_chunk = 65535,
> bpw = 16), the transfer will be rejected.
>
> This patch clamps max_chunk to the word size, preventing
I think align is a better word here than clamp.
> the transfer from being rejected.
>
> Signed-off-by: Yunhao Tian
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 71b646c4131f..440dc9fec6cc 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -1182,6 +1182,15 @@ int mipi_dbi_spi_transfer(struct spi_device *spi, u32
> speed_hz,
> struct spi_message m;
> size_t chunk;
> int ret;
> + int w_size;
> +
> + if (bpw <= 8)
> + w_size = 1;
> + else if (bpw <= 16)
> + w_size = 2;
> + else
> + w_size = 4;
> + max_chunk -= (max_chunk % w_size);
mipi_dbi_spi_transfer() is only called with bpw= 8 or 16, so I think
this can be simplified to: max_chunk = ALIGN_DOWN(max_chunk, 2);
We might shorten the max transfer by one byte when bpw=8, but that
doesn't matter. A short comment explaining why we need this would be nice.
Please add a fixes tag so the patch is backported to the stable kernels:
Fixes: d23d4d4dac01 ("drm/tinydrm: Move tinydrm_spi_transfer()")
Noralf.
>
> spi_message_init_with_transfers(&m, &tr, 1);
>
Re: drm/msm/dsi: fix error checks and return values for DSI xmit functions
Hi Dmitry,
On 2022-04-02 02:11:04, Dmitry Baryshkov wrote:
> As noticed by Dan ([1] an the followup thread) there are multiple issues
> with the return values for MSM DSI command transmission callback. In
> the error case it can easily return a positive value when it should
> have returned a proper error code.
>
> This commits attempts to fix these issues both in TX and in RX paths.
>
> [1]: https://lore.kernel.org/linux-arm-msm/20211001123617.GH2283@kili/
>
> Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> Reported-by: Dan Carpenter
> Signed-off-by: Dmitry Baryshkov
> Reviewed-by: Abhinav Kumar
Thank you for your patience waiting for the requested tests; this patch
seems to have no adverse effect on our cmdmode panels.
Tested-by: Marijn Suijten
On the following devices:
- Sony Xperia X (Loire Suzu, MSM8976), on Linux 5.17;
- Sony Xperia 10 II (Seine PDX201, SM6125), on -next 20220318;
- Sony Xperia XA2 Ultra (Nile Discovery, SDM630), on Linux 5.16.
Apologies for the older kernel versions, that's what happens when having
too many patches to dig through and too little hobby time to send them.
Let me know if there's a patch dependency that you like to be included.
- Marijn
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index d51e70fab93d..8925f60fd9ec 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1341,10 +1341,10 @@ static int dsi_cmds2buf_tx(struct msm_dsi_host
> *msm_host,
> dsi_get_bpp(msm_host->format) / 8;
>
> len = dsi_cmd_dma_add(msm_host, msg);
> - if (!len) {
> + if (len < 0) {
> pr_err("%s: failed to add cmd type = 0x%x\n",
> __func__, msg->type);
> - return -EINVAL;
> + return len;
> }
>
> /* for video mode, do not send cmds more than
> @@ -1363,10 +1363,14 @@ static int dsi_cmds2buf_tx(struct msm_dsi_host
> *msm_host,
> }
>
> ret = dsi_cmd_dma_tx(msm_host, len);
> - if (ret < len) {
> - pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x, len=%d\n",
> - __func__, msg->type, (*(u8 *)(msg->tx_buf)), len);
> - return -ECOMM;
> + if (ret < 0) {
> + pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x, len=%d,
> ret=%d\n",
> + __func__, msg->type, (*(u8 *)(msg->tx_buf)), len, ret);
> + return ret;
> + } else if (ret < len) {
> + pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x, ret=%d
> len=%d\n",
> + __func__, msg->type, (*(u8 *)(msg->tx_buf)), ret, len);
> + return -EIO;
> }
>
> return len;
> @@ -2092,9 +2096,12 @@ int msm_dsi_host_cmd_rx(struct mipi_dsi_host *host,
> }
>
> ret = dsi_cmds2buf_tx(msm_host, msg);
> - if (ret < msg->tx_len) {
> + if (ret < 0) {
> pr_err("%s: Read cmd Tx failed, %d\n", __func__, ret);
> return ret;
> + } else if (ret < msg->tx_len) {
> + pr_err("%s: Read cmd Tx failed, too short: %d\n",
> __func__, ret);
> + return -ECOMM;
> }
>
> /*
[Bug 215842] PC freeze sidn kernel 5.17.x
https://bugzilla.kernel.org/show_bug.cgi?id=215842 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- I presume your Radeon RX GPU is driving everything. Please refile here: https://gitlab.freedesktop.org/drm/amd/-/issues while providing all the necessary details. Also please search for existing bug reports, this could be already known. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215839] distorted video playback with hybrid GPU (DRI_PRIME=1, Radeon HD 6470M and Intel-GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=215839 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 0/2] Update AMDGPU glossary and MAINTAINERS
Am 15.04.22 um 21:50 schrieb Tales Lelo da Aparecida: I was handling the request from [0] and then I noticed that some AMD developers were missing from get_maintainers output due to the lack of a reference to their documentation in the MAINTAINERS file. Acked-by: Christian König [0] https://gitlab.freedesktop.org/drm/amd/-/issues/1939#note_1309737 Tales Lelo da Aparecida (2): Documentation/gpu: Add entries to amdgpu glossary MAINTAINERS: add docs entry to AMDGPU Documentation/gpu/amdgpu/amdgpu-glossary.rst | 13 + MAINTAINERS | 1 + 2 files changed, 14 insertions(+)
Re: [PATCH V2 1/3] dt-bindings: display: mediatek: Update disp_aal binding for MT8183
Rob Herring 於 2022年4月14日 週四 上午7:02寫道： > > On Mon, 11 Apr 2022 11:58:41 +0800, Rex-BC Chen wrote: > > The driver data of MT8183 and MT8173 are different. > > > > For MT8173, the gamma module is inside disp_aal. When we need to adjust > > gamma value, we need to use "has_gamma" to control gamma function > > inside disp_aal to adjust the gamma value. > > > > For successors like MT8183, disp_gamma is separated from disp_aal. We > > just need to control disp_gamma directly and don't need to control gamma > > function inside disp_aal. > > > > With this modification, the driver doesn't require any functional changes. > > We only update the dt-binding and DTS node to make it clear. > > > > Signed-off-by: Rex-BC Chen > > Reviewed-by: AngeloGioacchino Del Regno > > > > --- > > .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > Acked-by: Rob Herring Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang.
Re: [PATCH V2 3/3] dt-bindings: display: mediatek: Update disp_aal binding for MT8192 and MT8195
Rob Herring 於 2022年4月14日 週四 上午7:02寫道： > > On Mon, 11 Apr 2022 11:58:43 +0800, Rex-BC Chen wrote: > > Disp_aal of MT8192 and MT8195 are fully compatible with disp_aal of > > MT8183. Therefore, we move the them to item "mediatek,mt8183-disp-aal". > > > > Signed-off-by: Rex-BC Chen > > --- > > .../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Acked-by: Rob Herring Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang.
[PATCH] drm/i915/migrate: fix semicolon.cocci warnings
From: kernel test robot
drivers/gpu/drm/i915/gt/intel_migrate.c:643:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable
lmem obj")
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-gt
head: bcfc713f11f957711f9494f69c740b95ed335d57
commit: da0595ae91da837929a00470ab40546090e5b9ae [9/9] drm/i915/migrate: Evict
and restore the flatccs capable lmem obj
:: branch date: 14 hours ago
:: commit date: 2 days ago
drivers/gpu/drm/i915/gt/intel_migrate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -640,7 +640,7 @@ static int scatter_list_length(struct sc
while (sg && sg_dma_len(sg)) {
len += sg_dma_len(sg);
sg = sg_next(sg);
- };
+ }
return len;
}
[drm-intel:for-linux-next-gt 9/9] drivers/gpu/drm/i915/gt/intel_migrate.c:643:2-3: Unneeded semicolon
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-gt head: bcfc713f11f957711f9494f69c740b95ed335d57 commit: da0595ae91da837929a00470ab40546090e5b9ae [9/9] drm/i915/migrate: Evict and restore the flatccs capable lmem obj config: x86_64-randconfig-c002 (https://download.01.org/0day-ci/archive/20220416/202204162238.whnwriag-...@intel.com/config) compiler: gcc-11 (Debian 11.2.0-19) 11.2.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot cocci warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/gt/intel_migrate.c:643:2-3: Unneeded semicolon Please review and possibly fold the followup patch. -- 0-DAY CI Kernel Test Service https://01.org/lkp
[PATCH] drm/amdgpu/powerplay/vega10: fix minmax.cocci warnings
From: kernel test robot Use max to simplify the code. Generated by: scripts/coccinelle/misc/minmax.cocci CC: Denis Efremov Reported-by: kernel test robot Signed-off-by: kernel test robot Signed-off-by: Julia Lawall --- tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 028192fea1de083f4f12bfb1eb7c4d7beb5c8ecd commit: 5f66f73b9ff4dcabd4e2405ba9c32e80e02f9408 coccinelle: misc: add minmax script :: branch date: 17 hours ago :: commit date: 12 months ago Please take the patch only if it's a positive warning. Thanks! drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c @@ -345,12 +345,10 @@ static int vega10_odn_initial_default_se odn_table->min_vddc = dep_table[0]->entries[0].vddc; i = od_table[2]->count - 1; - od_table[2]->entries[i].clk = hwmgr->platform_descriptor.overdriveLimit.memoryClock > od_table[2]->entries[i].clk ? - hwmgr->platform_descriptor.overdriveLimit.memoryClock : - od_table[2]->entries[i].clk; - od_table[2]->entries[i].vddc = odn_table->max_vddc > od_table[2]->entries[i].vddc ? - odn_table->max_vddc : - od_table[2]->entries[i].vddc; + od_table[2]->entries[i].clk = max(hwmgr->platform_descriptor.overdriveLimit.memoryClock, + od_table[2]->entries[i].clk); + od_table[2]->entries[i].vddc = max(odn_table->max_vddc, + od_table[2]->entries[i].vddc); return 0; }
Re: [PATCH 2/2] MAINTAINERS: add docs entry to AMDGPU
Hi Bagas Sanjaya, Em sáb., 16 de abr. de 2022 às 02:47, Bagas Sanjaya escreveu: > On 4/16/22 02:50, Tales Lelo da Aparecida wrote: > > To make sure maintainers of amdgpu drivers are aware of any changes > > in their documentation, add its entry to MAINTAINERS. > > > > Did you mean the Documentation/gpu/amdgpu/ is maintained by dri-devel? `Documentation/gpu/amdgpu/` should be maintained by "RADEON and AMDGPU DRM DRIVERS" developers, which are part of the dri-devel community. Kind regards
[PATCH] drm/i915: change node clearing from memset to initialization
In insert_mappable_node(), the parameter node is
cleared late in node's use with memset.
insert_mappable_node() is a singleton, called only
from i915_gem_gtt_prepare() which itself is only
called by i915_gem_gtt_pread() and
i915_gem_gtt_pwrite_fast() where the definition of
node originates.
Instead of using memset, initialize node to 0 at it's
definitions. And remove unneeded clearing of the flags
element.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e10187cd0a0..7dbd0b325c43 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -69,7 +69,6 @@ insert_mappable_node(struct i915_ggtt *ggtt, struct
drm_mm_node *node, u32 size)
if (err)
return err;
- memset(node, 0, sizeof(*node));
err = drm_mm_insert_node_in_range(&ggtt->vm.mm, node,
size, 0, I915_COLOR_UNEVICTABLE,
0, ggtt->mappable_end,
@@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct
drm_i915_gem_object *obj,
goto err_ww;
} else if (!IS_ERR(vma)) {
node->start = i915_ggtt_offset(vma);
- node->flags = 0;
} else {
ret = insert_mappable_node(ggtt, node, PAGE_SIZE);
if (ret)
@@ -381,7 +379,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
intel_wakeref_t wakeref;
- struct drm_mm_node node;
+ struct drm_mm_node node = {};
void __user *user_data;
struct i915_vma *vma;
u64 remain, offset;
@@ -538,7 +536,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_runtime_pm *rpm = &i915->runtime_pm;
intel_wakeref_t wakeref;
- struct drm_mm_node node;
+ struct drm_mm_node node = {};
struct i915_vma *vma;
u64 remain, offset;
void __user *user_data;
--
2.27.0
Re: drm/msm/dsi: fix error checks and return values for DSI xmit functions
On Sat, 16 Apr 2022 at 12:12, Marijn Suijten
wrote:
>
> Hi Dmitry,
>
> On 2022-04-02 02:11:04, Dmitry Baryshkov wrote:
> > As noticed by Dan ([1] an the followup thread) there are multiple issues
> > with the return values for MSM DSI command transmission callback. In
> > the error case it can easily return a positive value when it should
> > have returned a proper error code.
> >
> > This commits attempts to fix these issues both in TX and in RX paths.
> >
> > [1]: https://lore.kernel.org/linux-arm-msm/20211001123617.GH2283@kili/
> >
> > Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
> > Reported-by: Dan Carpenter
> > Signed-off-by: Dmitry Baryshkov
> > Reviewed-by: Abhinav Kumar
>
> Thank you for your patience waiting for the requested tests; this patch
> seems to have no adverse effect on our cmdmode panels.
>
> Tested-by: Marijn Suijten
>
> On the following devices:
> - Sony Xperia X (Loire Suzu, MSM8976), on Linux 5.17;
> - Sony Xperia 10 II (Seine PDX201, SM6125), on -next 20220318;
> - Sony Xperia XA2 Ultra (Nile Discovery, SDM630), on Linux 5.16.
>
> Apologies for the older kernel versions, that's what happens when having
> too many patches to dig through and too little hobby time to send them.
> Let me know if there's a patch dependency that you like to be included.
Thank you for the confirmation! No, no hidden dependencies.
>
> - Marijn
>
> > ---
> > drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index d51e70fab93d..8925f60fd9ec 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -1341,10 +1341,10 @@ static int dsi_cmds2buf_tx(struct msm_dsi_host
> > *msm_host,
> > dsi_get_bpp(msm_host->format) / 8;
> >
> > len = dsi_cmd_dma_add(msm_host, msg);
> > - if (!len) {
> > + if (len < 0) {
> > pr_err("%s: failed to add cmd type = 0x%x\n",
> > __func__, msg->type);
> > - return -EINVAL;
> > + return len;
> > }
> >
> > /* for video mode, do not send cmds more than
> > @@ -1363,10 +1363,14 @@ static int dsi_cmds2buf_tx(struct msm_dsi_host
> > *msm_host,
> > }
> >
> > ret = dsi_cmd_dma_tx(msm_host, len);
> > - if (ret < len) {
> > - pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x,
> > len=%d\n",
> > - __func__, msg->type, (*(u8 *)(msg->tx_buf)), len);
> > - return -ECOMM;
> > + if (ret < 0) {
> > + pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x, len=%d,
> > ret=%d\n",
> > + __func__, msg->type, (*(u8 *)(msg->tx_buf)), len,
> > ret);
> > + return ret;
> > + } else if (ret < len) {
> > + pr_err("%s: cmd dma tx failed, type=0x%x, data0=0x%x, ret=%d
> > len=%d\n",
> > + __func__, msg->type, (*(u8 *)(msg->tx_buf)), ret,
> > len);
> > + return -EIO;
> > }
> >
> > return len;
> > @@ -2092,9 +2096,12 @@ int msm_dsi_host_cmd_rx(struct mipi_dsi_host *host,
> > }
> >
> > ret = dsi_cmds2buf_tx(msm_host, msg);
> > - if (ret < msg->tx_len) {
> > + if (ret < 0) {
> > pr_err("%s: Read cmd Tx failed, %d\n", __func__, ret);
> > return ret;
> > + } else if (ret < msg->tx_len) {
> > + pr_err("%s: Read cmd Tx failed, too short: %d\n",
> > __func__, ret);
> > + return -ECOMM;
> > }
> >
> > /*
--
With best wishes
Dmitry
Re: [PATCH] drm/i915: change node clearing from memset to initialization
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> In insert_mappable_node(), the parameter node is
> cleared late in node's use with memset.
> insert_mappable_node() is a singleton, called only
> from i915_gem_gtt_prepare() which itself is only
> called by i915_gem_gtt_pread() and
> i915_gem_gtt_pwrite_fast() where the definition of
> node originates.
>
> Instead of using memset, initialize node to 0 at it's
> definitions.
trivia: /it's/its/
Only reason _not_ to do this is memset is guaranteed to
zero any padding that might go to userspace.
But it doesn't seem there is any padding anyway nor is
the struct available to userspace.
So this seems fine though it might increase overall code
size a tiny bit.
I do have a caveat: see below:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
[]
> @@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct
> drm_i915_gem_object *obj,
> goto err_ww;
> } else if (!IS_ERR(vma)) {
> node->start = i915_ggtt_offset(vma);
> - node->flags = 0;
Why is this unneeded?
from: drm_mm_insert_node_in_range which can set node->flags
__set_bit(DRM_MM_NODE_ALLOCATED_BIT, &node->flags);
[PATCH] drm/radeon/kms: change evergreen_default_state table from global to static
evergreen_default_state and evergreen_default_size are only
used in evergreen.c. Single file symbols should be static.
So move their definitions to evergreen_blit_shaders.h
and change their storage-class-specifier to static.
Remove unneeded evergreen_blit_shader.c
evergreen_ps/vs definitions were removed with
commit 4f8629675800 ("drm/radeon/kms: remove r6xx+ blit copy routines")
So their declarations in evergreen_blit_shader.h
are not needed, so remove them.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/Makefile | 2 +-
.../gpu/drm/radeon/evergreen_blit_shaders.c | 303 --
.../gpu/drm/radeon/evergreen_blit_shaders.h | 278 +++-
3 files changed, 274 insertions(+), 309 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/evergreen_blit_shaders.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 4deedaacd655..1045d2c46a76 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -41,7 +41,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o \
radeon_pm.o atombios_dp.o r600_hdmi.o dce3_1_afmt.o \
- evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
+ evergreen.o evergreen_cs.o \
evergreen_hdmi.o radeon_trace_points.o ni.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
radeon_prime.o cik.o cik_blit_shaders.o \
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
b/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
deleted file mode 100644
index 1a96ddb3e5ed..
--- a/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
+++ /dev/null
@@ -1,303 +0,0 @@
-/*
- * Copyright 2010 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- * Alex Deucher
- */
-
-#include
-#include
-#include
-
-/*
- * evergreen cards need to use the 3D engine to blit data which requires
- * quite a bit of hw state setup. Rather than pull the whole 3D driver
- * (which normally generates the 3D state) into the DRM, we opt to use
- * statically generated state tables. The register state and shaders
- * were hand generated to support blitting functionality. See the 3D
- * driver or documentation for descriptions of the registers and
- * shader instructions.
- */
-
-const u32 evergreen_default_state[] =
-{
- 0xc0016900,
- 0x023b,
- 0x, /* SQ_LDS_ALLOC_PS */
-
- 0xc0066900,
- 0x0240,
- 0x, /* SQ_ESGS_RING_ITEMSIZE */
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
-
- 0xc0046900,
- 0x0247,
- 0x, /* SQ_GS_VERT_ITEMSIZE */
- 0x,
- 0x,
- 0x,
-
- 0xc0026900,
- 0x0010,
- 0x, /* DB_Z_INFO */
- 0x, /* DB_STENCIL_INFO */
-
- 0xc0016900,
- 0x0200,
- 0x, /* DB_DEPTH_CONTROL */
-
- 0xc0066900,
- 0x,
- 0x0060, /* DB_RENDER_CONTROL */
- 0x, /* DB_COUNT_CONTROL */
- 0x, /* DB_DEPTH_VIEW */
- 0x002a, /* DB_RENDER_OVERRIDE */
- 0x, /* DB_RENDER_OVERRIDE2 */
- 0x, /* DB_HTILE_DATA_BASE */
-
- 0xc0026900,
- 0x000a,
- 0x, /* DB_STENCIL_CLEAR */
- 0x, /* DB_DEPTH_CLEAR */
-
- 0xc0016900,
- 0x02dc,
- 0xaa00, /* DB_ALPHA_TO_MASK */
-
- 0xc0016900,
- 0x0080,
- 0x, /* PA_SC_WINDOW_OFFSET */
-
- 0xc00d6900,
- 0x0083,
- 0x, /* PA_SC_CLIPRECT_RULE */
- 0x, /* PA_SC_CLIPRECT_0_TL */
- 0x20002000, /* PA_SC_CLIPRECT_0_BR
Re: [PATCH] drm/i915: change node clearing from memset to initialization
On 4/16/22 11:33 AM, Joe Perches wrote:
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
In insert_mappable_node(), the parameter node is
cleared late in node's use with memset.
insert_mappable_node() is a singleton, called only
from i915_gem_gtt_prepare() which itself is only
called by i915_gem_gtt_pread() and
i915_gem_gtt_pwrite_fast() where the definition of
node originates.
Instead of using memset, initialize node to 0 at it's
definitions.
trivia: /it's/its/
Only reason _not_ to do this is memset is guaranteed to
zero any padding that might go to userspace.
But it doesn't seem there is any padding anyway nor is
the struct available to userspace.
So this seems fine though it might increase overall code
size a tiny bit.
I do have a caveat: see below:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
[]
@@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct
drm_i915_gem_object *obj,
goto err_ww;
} else if (!IS_ERR(vma)) {
node->start = i915_ggtt_offset(vma);
- node->flags = 0;
Why is this unneeded?
node = {} initializes all of node's elements to 0, including this one.
Tom
from: drm_mm_insert_node_in_range which can set node->flags
__set_bit(DRM_MM_NODE_ALLOCATED_BIT, &node->flags);
Re: [PATCH] drm/i915: change node clearing from memset to initialization
On Sat, 2022-04-16 at 13:48 -0700, Tom Rix wrote:
> On 4/16/22 11:33 AM, Joe Perches wrote:
> > On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
> > > In insert_mappable_node(), the parameter node is
> > > cleared late in node's use with memset.
> > > insert_mappable_node() is a singleton, called only
> > > from i915_gem_gtt_prepare() which itself is only
> > > called by i915_gem_gtt_pread() and
> > > i915_gem_gtt_pwrite_fast() where the definition of
> > > node originates.
> > >
> > > Instead of using memset, initialize node to 0 at it's
> > > definitions.
> > trivia: /it's/its/
> >
> > Only reason _not_ to do this is memset is guaranteed to
> > zero any padding that might go to userspace.
> >
> > But it doesn't seem there is any padding anyway nor is
> > the struct available to userspace.
> >
> > So this seems fine though it might increase overall code
> > size a tiny bit.
> >
> > I do have a caveat: see below:
> >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > []
> > > @@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct
> > > drm_i915_gem_object *obj,
> > > goto err_ww;
> > > } else if (!IS_ERR(vma)) {
> > > node->start = i915_ggtt_offset(vma);
> > > - node->flags = 0;
> > Why is this unneeded?
>
> node = {} initializes all of node's elements to 0, including this one.
true, but could the call to insert_mappable_node combined with the
retry goto in i915_gem_gtt_prepare set this to non-zero?
Re: [PATCH v3] drm: of: Properly try all possible cases for bridge/panel detection
Hi Paul, This patch breaks the ingenic-drm driver. It calls drm_of_find_panel_or_bridge(np, 0, i, ...) starting for i=0, until -ENODEV is returned, which does not happen anymore. The idea is to probe all the connected panels/bridges, should it be done differently now? Cheers, -Paul
Re: [PATCH] drm/i915: change node clearing from memset to initialization
On 4/16/22 2:04 PM, Joe Perches wrote:
On Sat, 2022-04-16 at 13:48 -0700, Tom Rix wrote:
On 4/16/22 11:33 AM, Joe Perches wrote:
On Sat, 2022-04-16 at 13:23 -0400, Tom Rix wrote:
In insert_mappable_node(), the parameter node is
cleared late in node's use with memset.
insert_mappable_node() is a singleton, called only
from i915_gem_gtt_prepare() which itself is only
called by i915_gem_gtt_pread() and
i915_gem_gtt_pwrite_fast() where the definition of
node originates.
Instead of using memset, initialize node to 0 at it's
definitions.
trivia: /it's/its/
Only reason _not_ to do this is memset is guaranteed to
zero any padding that might go to userspace.
But it doesn't seem there is any padding anyway nor is
the struct available to userspace.
So this seems fine though it might increase overall code
size a tiny bit.
I do have a caveat: see below:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
[]
@@ -328,7 +327,6 @@ static struct i915_vma *i915_gem_gtt_prepare(struct
drm_i915_gem_object *obj,
goto err_ww;
} else if (!IS_ERR(vma)) {
node->start = i915_ggtt_offset(vma);
- node->flags = 0;
Why is this unneeded?
node = {} initializes all of node's elements to 0, including this one.
true, but could the call to insert_mappable_node combined with the
retry goto in i915_gem_gtt_prepare set this to non-zero?
Yikes!
I'll add that back.
Thanks for pointing it out.
Tom
[PATCH v2] drm/i915: change node clearing from memset to initialization
In insert_mappable_node(), the parameter node is
cleared late in node's use with memset.
insert_mappable_node() is a singleton, called only
from i915_gem_gtt_prepare() which itself is only
called by i915_gem_gtt_pread() and
i915_gem_gtt_pwrite_fast() where the definition of
node originates.
Instead of using memset, initialize node to 0 at its
definitions.
Signed-off-by: Tom Rix
---
v2: restore clearing of flags
drivers/gpu/drm/i915/i915_gem.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e10187cd0a0..268b1f66b873 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -69,7 +69,6 @@ insert_mappable_node(struct i915_ggtt *ggtt, struct
drm_mm_node *node, u32 size)
if (err)
return err;
- memset(node, 0, sizeof(*node));
err = drm_mm_insert_node_in_range(&ggtt->vm.mm, node,
size, 0, I915_COLOR_UNEVICTABLE,
0, ggtt->mappable_end,
@@ -381,7 +380,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
intel_wakeref_t wakeref;
- struct drm_mm_node node;
+ struct drm_mm_node node = {};
void __user *user_data;
struct i915_vma *vma;
u64 remain, offset;
@@ -538,7 +537,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_runtime_pm *rpm = &i915->runtime_pm;
intel_wakeref_t wakeref;
- struct drm_mm_node node;
+ struct drm_mm_node node = {};
struct i915_vma *vma;
u64 remain, offset;
void __user *user_data;
--
2.27.0
Re: [PATCH v2 2/7] drm: mxsfb: Simplify LCDIF IRQ handling
On 4/7/22 10:01, Lucas Stach wrote: Am Donnerstag, dem 07.04.2022 um 00:03 +0200 schrieb Marek Vasut: On 4/6/22 21:41, Lucas Stach wrote: Am Freitag, dem 11.03.2022 um 18:05 +0100 schrieb Marek Vasut: The call to drm_crtc_vblank_off(&lcdif->crtc); disables IRQ generation from the LCDIF block already and this is called in mxsfb_load() before request_irq(), so explicitly disabling IRQ using custom function like mxsfb_irq_disable() is not needed, remove it. Have you checked that the drm_vblank_off in probe actually results in a call to mxsfb_crtc_disable_vblank? From my reading of the core code, this should be a no-op without a previous drm_vblank_on, so it would not result in the desired masking before the IRQ is requested. I must've missed the vblank->enabled check, but then, I am also not getting any interrupts, so presumably they are already disabled after the IP is reset. Yep, it should be the default for every peripheral to not send any unsolicited interrupts. But then I don't see explicit reset of the IP in the driver probe. So maybe this is a workaround for situation where something running before Linux has already enabled the display controller and for whatever reason also enabled the interrupt requests? Either we should have a proper reset of the block in the probe path, or this interrupt masking must be kept in one form or the other. My vote would be on just masking the IRQs and dropping the useless drm_vblank_off. I can just discard this patch, OK.
Re: [PATCH v2 1/7] drm: mxsfb: Simplify LCDIF clock handling
On 4/7/22 09:57, Lucas Stach wrote: Am Mittwoch, dem 06.04.2022 um 23:45 +0200 schrieb Marek Vasut: On 4/6/22 21:32, Lucas Stach wrote: Hi Marek, Hi, Am Freitag, dem 11.03.2022 um 18:05 +0100 schrieb Marek Vasut: The current clock handling in the LCDIF driver is a convoluted mess. Here we agree... Implement runtime PM ops which turn the clock ON and OFF and let the pm_runtime_get_sync()/pm_runtime_put_sync() calls in .atomic_enable and .atomic_disable callbacks turn the clock ON and OFF at the right time. This requires slight reordering in mxsfb_crtc_atomic_enable() and mxsfb_crtc_atomic_disable(), since all the register accesses must happen only with clock enabled and clock frequency configuration must happen with clock disabled. ... on that one I don't. Please don't move the pixel clock into the RPM calls. We have a very well defined point between atomic enable/disable where the pixel clock is actually needed. All the other configuration accesses don't need the pixel clock to be active. On the other hand, "all the other" configuration happens during probe, at which point all the clock are enabled anyway. And then during runtime, the pixel clock of this IP are either enabled or this IP is completely shut down. So, where exactly does this patch make the clock handling any worse than it currently is ? There is an even stronger argument: runtime PM does not guarantee that the runtime_suspend is actually called after you put your last reference. A simple "echo on > /sys/your-device/power/control" will prevent the device from ever entering runtime suspend. So if you have a clock like the pixel clock that _needs_ to be disabled for configuration purposes you _must_ not handle this clock via RPM, but via explicit clock handling in the driver. OK, patch discarded.
Re: [PATCH 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant
On 4/7/22 10:48, Lucas Stach wrote:
[...]
+static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
+{
+ struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
+ u32 ctrl = 0;
+
+ if (m->flags & DRM_MODE_FLAG_PHSYNC)
+ ctrl |= CTRL_INV_HS;
+ if (m->flags & DRM_MODE_FLAG_PVSYNC)
+ ctrl |= CTRL_INV_VS;
+ /* Make sure Data Enable is high active by default */
+ if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
+ ctrl |= CTRL_INV_DE;
The above three controls seems to have the wrong polarity. Bit set
means low active according to the register documentation and the PVI in
the HDMI path, which has configurable input signal polarity, seems to
agree with that.
I seem to recall seeing something about DE polarity being inverted in
odd way in the NXP downstream driver, and differently for each LCDIF
instance. Isn't that what you're seeing with HDMI ?
Yes, there seems to be some funky business going on here. I guess for
the MIPI DSI path it's the same as on the i.MX8MM where the DSI core
always expects the sync to be low active IIRC. In the HDMI path there
is a block called PVI, which can be configured on what sync polarity to
expect on the input. My experiments show that if I program the PVI for
high active sync signals, the CTRL_INV_* bits must not be set in the
LCDIF for the PVI to pick up the signal, which is consistent with the
documentation of those bits in the LCDIF register map.
In terms of DE invert, the downstream driver indicates it is needed for
both HDMI and DSI and not for LDB, and I already tested the later two
(DSI and LDB). Maybe the HDMI bridge driver needs DE polarity inverted
in one of the atomic callbacks ?
[PATCH v2 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which is really a fork of MXSFB driver with the
i.MX8MP LCDIF variant handling filled in.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: - Drop the pitch check from lcdif_fb_create()
- Drop connector caching
- Wait for shadow load bit to be cleared in IRQ handler
- Make all clock mandatory and grab them all by name
- Wait for EN to be cleared in lcdif_disable_controller
- Rename to imx-lcdif
- Move shadow load to atomic_flush
---
drivers/gpu/drm/mxsfb/Kconfig | 16 +
drivers/gpu/drm/mxsfb/Makefile | 2 +
drivers/gpu/drm/mxsfb/lcdif_drv.c | 361 +
drivers/gpu/drm/mxsfb/lcdif_drv.h | 47 +++
drivers/gpu/drm/mxsfb/lcdif_kms.c | 484 +
drivers/gpu/drm/mxsfb/lcdif_regs.h | 243 +++
6 files changed, 1153 insertions(+)
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_drv.h
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_kms.c
create mode 100644 drivers/gpu/drm/mxsfb/lcdif_regs.h
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 987170e16ebd6..873551b4552f5 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -19,3 +19,19 @@ config DRM_MXSFB
i.MX28, i.MX6SX, i.MX7 and i.MX8M).
If M is selected the module will be called mxsfb.
+
+config DRM_IMX_LCDIF
+ tristate "i.MX LCDIFv3 LCD controller"
+ depends on DRM && OF
+ depends on COMMON_CLK
+ select DRM_MXS
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_PANEL
+ select DRM_PANEL_BRIDGE
+ help
+ Choose this option if you have an LCDIFv3 LCD controller.
+ Those devices are found in various i.MX SoC (i.MX8MP,
+ i.MXRT).
+
+ If M is selected the module will be called imx-lcdif.
diff --git a/drivers/gpu/drm/mxsfb/Makefile b/drivers/gpu/drm/mxsfb/Makefile
index 26d153896d720..3fa44059b9d85 100644
--- a/drivers/gpu/drm/mxsfb/Makefile
+++ b/drivers/gpu/drm/mxsfb/Makefile
@@ -1,3 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
mxsfb-y := mxsfb_drv.o mxsfb_kms.o
obj-$(CONFIG_DRM_MXSFB)+= mxsfb.o
+imx-lcdif-y := lcdif_drv.o lcdif_kms.o
+obj-$(CONFIG_DRM_IMX_LCDIF) += imx-lcdif.o
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
b/drivers/gpu/drm/mxsfb/lcdif_drv.c
new file mode 100644
index 0..3e29c8a768487
--- /dev/null
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2022 Marek Vasut
+ *
+ * This code is based on drivers/gpu/drm/mxsfb/mxsfb*
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "lcdif_drv.h"
+#include "lcdif_regs.h"
+
+static struct drm_framebuffer *
+lcdif_fb_create(struct drm_device *dev, struct drm_file *file_priv,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ const struct drm_format_info *info;
+
+ info = drm_get_format_info(dev, mode_cmd);
+ if (!info)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
+static const struct drm_mode_config_funcs lcdif_mode_config_funcs = {
+ .fb_create = lcdif_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct drm_mode_config_helper_funcs lcdif_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
+{
+ struct drm_device *drm = lcdif->drm;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ int ret;
+
+ ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel,
+ &bridge);
+ if (ret)
+ return ret;
+
+ if (panel) {
+ bridge = devm_drm_panel_bridge_add_typed(drm->dev, panel,
+
DRM_MODE_CONNECTOR_DPI);
+ if (IS_ERR(bridge))
+ return PTR_ERR(bridge);
+ }
+
+ if (!bridge)
+ return -ENODEV;
+
+ ret = drm_bridge_attach(&lcdif->encoder, bridge, NULL, 0);
+ if (ret)
+ return dev_err_probe(drm->dev, ret, "Failed to attach
bridge\n"
[PATCH v2 1/2] dt-bindings: lcdif: Add compatible for i.MX8MP
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Rob Herring Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner Cc: devicet...@vger.kernel.org --- V2: No change --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 900a56cae80e6..876015a44a1e6 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx23-lcdif - fsl,imx28-lcdif - fsl,imx6sx-lcdif + - fsl,imx8mp-lcdif - items: - enum: - fsl,imx6sl-lcdif -- 2.35.1
[PATCH v3 1/4] drm: mxsfb: Wrap FIFO reset and comments into mxsfb_reset_block()
Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up.
No functional change.
Reviewed-by: Lucas Stach
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: Add RB from Lucas
V3: Rebase on latest next and discarded clock and irq cleanups
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 36 +--
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 4cfb6c0016799..45cabe0960769 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -191,6 +191,12 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
{
int ret;
+ /*
+* It seems, you can't re-program the controller if it is still
+* running. This may lead to shifted pictures (FIFO issue?), so
+* first stop the controller and drain its FIFOs.
+*/
+
ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_SFTRST);
if (ret)
return ret;
@@ -201,7 +207,20 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
if (ret)
return ret;
- return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+ if (ret)
+ return ret;
+
+ /* Clear the FIFOs */
+ writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
+ readl(mxsfb->base + LCDC_CTRL1);
+ writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
+ readl(mxsfb->base + LCDC_CTRL1);
+
+ if (mxsfb->devdata->has_overlay)
+ writel(0, mxsfb->base + LCDC_AS_CTRL);
+
+ return 0;
}
static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
@@ -228,26 +247,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
- /*
-* It seems, you can't re-program the controller if it is still
-* running. This may lead to shifted pictures (FIFO issue?), so
-* first stop the controller and drain its FIFOs.
-*/
-
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb);
if (err)
return;
- /* Clear the FIFOs */
- writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
- readl(mxsfb->base + LCDC_CTRL1);
- writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- readl(mxsfb->base + LCDC_CTRL1);
-
- if (mxsfb->devdata->has_overlay)
- writel(0, mxsfb->base + LCDC_AS_CTRL);
-
mxsfb_set_formats(mxsfb, bus_format);
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
--
2.35.1
[PATCH v3 2/4] drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr()
Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr() to correctly handle
FB offset.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V3: New patch
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 45cabe0960769..6697a600b36f4 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -223,21 +223,6 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
return 0;
}
-static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
-{
- struct drm_framebuffer *fb = plane->state->fb;
- struct drm_gem_cma_object *gem;
-
- if (!fb)
- return 0;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
- if (!gem)
- return 0;
-
- return gem->paddr;
-}
-
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb,
const u32 bus_format)
{
@@ -350,6 +335,8 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
+ struct drm_plane_state *new_pstate =
drm_atomic_get_new_plane_state(state,
+
crtc->primary);
struct drm_bridge_state *bridge_state;
struct drm_device *drm = mxsfb->drm;
u32 bus_format = 0;
@@ -389,7 +376,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
mxsfb_crtc_mode_set_nofb(mxsfb, bus_format);
/* Write cur_buf as well to avoid an initial corrupt frame */
- paddr = mxsfb_get_fb_paddr(crtc->primary);
+ paddr = drm_fb_cma_get_gem_addr(new_pstate->fb, new_pstate, 0);
if (paddr) {
writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
@@ -492,9 +479,11 @@ static void mxsfb_plane_primary_atomic_update(struct
drm_plane *plane,
struct drm_atomic_state *state)
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
+ struct drm_plane_state *new_pstate =
drm_atomic_get_new_plane_state(state,
+
plane);
dma_addr_t paddr;
- paddr = mxsfb_get_fb_paddr(plane);
+ paddr = drm_fb_cma_get_gem_addr(new_pstate->fb, new_pstate, 0);
if (paddr)
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
}
@@ -510,7 +499,7 @@ static void mxsfb_plane_overlay_atomic_update(struct
drm_plane *plane,
dma_addr_t paddr;
u32 ctrl;
- paddr = mxsfb_get_fb_paddr(plane);
+ paddr = drm_fb_cma_get_gem_addr(new_pstate->fb, new_pstate, 0);
if (!paddr) {
writel(0, mxsfb->base + LCDC_AS_CTRL);
return;
--
2.35.1
[PATCH v3 4/4] drm: mxsfb: Reorder mxsfb_crtc_mode_set_nofb()
Reorder mxsfb_crtc_mode_set_nofb() such that all functions which perform register IO are called from one single location in this function. This is a clean up. No functional change. Reviewed-by: Lucas Stach Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner --- V2: Add RB from Lucas V3: Rebase on latest next and discarded clock and irq cleanups --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 1f0f08eab8e74..b7c70d269d2cb 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -282,15 +282,6 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, u32 bus_flags = mxsfb->connector->display_info.bus_flags; int err; - /* Mandatory eLCDIF reset as per the Reference Manual */ - err = mxsfb_reset_block(mxsfb); - if (err) - return; - - mxsfb_set_formats(mxsfb, bus_format); - - clk_set_rate(mxsfb->clk, m->crtc_clock * 1000); - if (mxsfb->bridge && mxsfb->bridge->timings) bus_flags = mxsfb->bridge->timings->input_bus_flags; @@ -301,6 +292,15 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, bus_flags); DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags); + /* Mandatory eLCDIF reset as per the Reference Manual */ + err = mxsfb_reset_block(mxsfb); + if (err) + return; + + mxsfb_set_formats(mxsfb, bus_format); + + clk_set_rate(mxsfb->clk, m->crtc_clock * 1000); + mxsfb_set_mode(mxsfb, bus_flags); } -- 2.35.1
[PATCH v3 3/4] drm: mxsfb: Factor out mxsfb_set_mode()
Pull mode registers programming from mxsfb_enable_controller() into
dedicated function mxsfb_set_mode(). This is a clean up. No functional
change.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: No change
V3: Rebase on latest next and discarded clock and irq cleanups
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 96 +--
1 file changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 6697a600b36f4..1f0f08eab8e74 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -96,6 +96,57 @@ static void mxsfb_set_formats(struct mxsfb_drm_private
*mxsfb,
writel(ctrl, mxsfb->base + LCDC_CTRL);
}
+static void mxsfb_set_mode(struct mxsfb_drm_private *mxsfb, u32 bus_flags)
+{
+ struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode;
+ u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
+
+ writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
+ TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
+ mxsfb->base + mxsfb->devdata->transfer_count);
+
+ vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
+
+ vdctrl0 = VDCTRL0_ENABLE_PRESENT | /* Always in DOTCLOCK mode */
+ VDCTRL0_VSYNC_PERIOD_UNIT |
+ VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
+ VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
+ if (m->flags & DRM_MODE_FLAG_PHSYNC)
+ vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
+ if (m->flags & DRM_MODE_FLAG_PVSYNC)
+ vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
+ /* Make sure Data Enable is high active by default */
+ if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
+ vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
+ /*
+* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
+* controllers VDCTRL0_DOTCLK is display centric.
+* Drive on positive edge -> display samples on falling edge
+* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
+*/
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
+ vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
+
+ writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
+
+ /* Frame length in lines. */
+ writel(m->crtc_vtotal, mxsfb->base + LCDC_VDCTRL1);
+
+ /* Line length in units of clocks or pixels. */
+ hsync_pulse_len = m->crtc_hsync_end - m->crtc_hsync_start;
+ writel(set_hsync_pulse_width(mxsfb, hsync_pulse_len) |
+ VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal),
+ mxsfb->base + LCDC_VDCTRL2);
+
+ writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) |
+ SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
+ mxsfb->base + LCDC_VDCTRL3);
+
+ writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
+ mxsfb->base + LCDC_VDCTRL4);
+
+}
+
static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
{
u32 reg;
@@ -229,7 +280,6 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
struct drm_device *drm = mxsfb->crtc.dev;
struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode;
u32 bus_flags = mxsfb->connector->display_info.bus_flags;
- u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
/* Mandatory eLCDIF reset as per the Reference Manual */
@@ -251,49 +301,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
bus_flags);
DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
- writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
- TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
- mxsfb->base + mxsfb->devdata->transfer_count);
-
- vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
-
- vdctrl0 = VDCTRL0_ENABLE_PRESENT | /* Always in DOTCLOCK mode */
- VDCTRL0_VSYNC_PERIOD_UNIT |
- VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
- VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
- if (m->flags & DRM_MODE_FLAG_PHSYNC)
- vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
- if (m->flags & DRM_MODE_FLAG_PVSYNC)
- vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
- /* Make sure Data Enable is high active by default */
- if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
- vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
- /*
-* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
-* controllers VDCTRL0_DOTCLK is display centric.
-* Drive on positive edge -> display samples on falling edge
-* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
-*/
- if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
-
[PATCH v2] drm: mxsfb: Obtain bus flags from bridge state
In case the MXSFB is connected to a bridge, attempt to obtain bus flags
from that bridge state too. The bus flags may specify e.g. the DE signal
polarity.
Acked-by: Alexander Stein
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
V2: Add AB from Alexander
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index b7c70d269d2cb..cd2a59e110c3a 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -275,6 +275,7 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
}
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb,
+struct drm_bridge_state *bridge_state,
const u32 bus_format)
{
struct drm_device *drm = mxsfb->crtc.dev;
@@ -284,6 +285,8 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
if (mxsfb->bridge && mxsfb->bridge->timings)
bus_flags = mxsfb->bridge->timings->input_bus_flags;
+ else if (bridge_state)
+ bus_flags = bridge_state->input_bus_cfg.flags;
DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
m->crtc_clock,
@@ -345,7 +348,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
struct drm_plane_state *new_pstate =
drm_atomic_get_new_plane_state(state,
crtc->primary);
- struct drm_bridge_state *bridge_state;
+ struct drm_bridge_state *bridge_state = NULL;
struct drm_device *drm = mxsfb->drm;
u32 bus_format = 0;
dma_addr_t paddr;
@@ -381,7 +384,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
if (!bus_format)
bus_format = MEDIA_BUS_FMT_RGB888_1X24;
- mxsfb_crtc_mode_set_nofb(mxsfb, bus_format);
+ mxsfb_crtc_mode_set_nofb(mxsfb, bridge_state, bus_format);
/* Write cur_buf as well to avoid an initial corrupt frame */
paddr = drm_fb_cma_get_gem_addr(new_pstate->fb, new_pstate, 0);
--
2.35.1
Re: [PATCH 1/2] Documentation/gpu: Add entries to amdgpu glossary
Dear Tales, Thank you for your patch. Am 15.04.22 um 21:50 schrieb Tales Lelo da Aparecida: Add missing acronyms to the amdgppu glossary. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1939#note_1309737 Signed-off-by: Tales Lelo da Aparecida --- Documentation/gpu/amdgpu/amdgpu-glossary.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 859dcec6c6f9..48829d097f40 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -8,12 +8,19 @@ we have a dedicated glossary for Display Core at .. glossary:: +active_cu_number + The number of CUs that are active on the system. The number of active + CUs may be less than SE * SH * CU depending on the board configuration. + CP Command Processor CPLIB Content Protection Library +CU + Compute unit Capitalize the U in *unit* as seems to be done in the rest of the files? + DFS Digital Frequency Synthesizer @@ -74,6 +81,12 @@ we have a dedicated glossary for Display Core at SDMA System DMA +SE + Shader Engine + +SH + SHader array No idea if the H should be capitalized. + SMU System Management Unit Kind regards, Paul
