[Bug 101691] [KBL] gfx corruption on windowed 3d-apps running on dGPU
https://bugs.freedesktop.org/show_bug.cgi?id=101691 Timo Aaltonen changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Component|DRM/Intel |DRM/AMDgpu QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | --- Comment #18 from Timo Aaltonen --- Turns out that setting amdgpu.dpm=0 fixes the corruption.. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/17] drm/msm: Support multiple ringbuffers
Hi Jordan,
[auto build test WARNING on v4.13-rc2]
[also build test WARNING on next-20170728]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-GPU-fixes-and-features-for-4-14/20170729-063809
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/msm/msm_drv.h:37:0,
from drivers/gpu/drm/msm/msm_gpu.h:24,
from drivers/gpu/drm/msm/msm_gpu.c:18:
drivers/gpu/drm/msm/msm_gpu.c: In function 'msm_gpu_init':
>> drivers/gpu/drm/msm/msm_gpu.c:743:31: warning: format '%lu' expects argument
>> of type 'long unsigned int', but argument 7 has type 'unsigned int'
>> [-Wformat=]
DRM_DEV_INFO_ONCE(drm->dev, "Only creating %lu ringbuffers\n",
^
include/drm/drmP.h:208:60: note: in definition of macro 'DRM_DEV_INFO'
drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt, \
^~~
>> drivers/gpu/drm/msm/msm_gpu.c:743:3: note: in expansion of macro
>> 'DRM_DEV_INFO_ONCE'
DRM_DEV_INFO_ONCE(drm->dev, "Only creating %lu ringbuffers\n",
^
vim +743 drivers/gpu/drm/msm/msm_gpu.c
648
649 int msm_gpu_init(struct drm_device *drm, struct platform_device *pdev,
650 struct msm_gpu *gpu, const struct msm_gpu_funcs *funcs,
651 const char *name, struct msm_gpu_config *config)
652 {
653 int i, ret, nr_rings = config->nr_rings;
654 void *memptrs;
655 uint64_t memptrs_iova;
656
657 if (WARN_ON(gpu->num_perfcntrs > ARRAY_SIZE(gpu->last_cntrs)))
658 gpu->num_perfcntrs = ARRAY_SIZE(gpu->last_cntrs);
659
660 gpu->dev = drm;
661 gpu->funcs = funcs;
662 gpu->name = name;
663
664 INIT_LIST_HEAD(&gpu->active_list);
665 INIT_WORK(&gpu->retire_work, retire_worker);
666 INIT_WORK(&gpu->recover_work, recover_worker);
667
668
669 setup_timer(&gpu->hangcheck_timer, hangcheck_handler,
670 (unsigned long)gpu);
671
672 spin_lock_init(&gpu->perf_lock);
673
674
675 /* Map registers: */
676 gpu->mmio = msm_ioremap(pdev, config->ioname, name);
677 if (IS_ERR(gpu->mmio)) {
678 ret = PTR_ERR(gpu->mmio);
679 goto fail;
680 }
681
682 /* Get Interrupt: */
683 gpu->irq = platform_get_irq_byname(pdev, config->irqname);
684 if (gpu->irq < 0) {
685 ret = gpu->irq;
686 dev_err(drm->dev, "failed to get irq: %d\n", ret);
687 goto fail;
688 }
689
690 ret = devm_request_irq(&pdev->dev, gpu->irq, irq_handler,
691 IRQF_TRIGGER_HIGH, gpu->name, gpu);
692 if (ret) {
693 dev_err(drm->dev, "failed to request IRQ%u: %d\n",
gpu->irq, ret);
694 goto fail;
695 }
696
697 ret = get_clocks(pdev, gpu);
698 if (ret)
699 goto fail;
700
701 gpu->ebi1_clk = msm_clk_get(pdev, "bus");
702 DBG("ebi1_clk: %p", gpu->ebi1_clk);
703 if (IS_ERR(gpu->ebi1_clk))
704 gpu->ebi1_clk = NULL;
705
706 /* Acquire regulators: */
707 gpu->gpu_reg = devm_regulator_get(&pdev->dev, "vdd");
708 DBG("gpu_reg: %p", gpu->gpu_reg);
709 if (IS_ERR(gpu->gpu_reg))
710 gpu->gpu_reg = NULL;
711
712 gpu->gpu_cx = devm_regulator_get(&pdev->dev, "vddcx");
713 DBG("gpu_cx: %p", gpu->gpu_cx);
714 if (IS_ERR(gpu->gpu_cx))
715 gpu->gpu_cx = NULL;
716
717 gpu->pdev = pdev;
718 platform_set_drvdata(pdev, gpu);
719
720 bs_init(gpu);
721
722 gpu->aspace = msm_gpu_create_address_space(gpu, p
Re: [PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.
Daniel Vetter writes: > On Tue, Jul 25, 2017 at 11:27:16AM -0700, Eric Anholt wrote: >> Chris Wilson pointed out this little cleanup in a review of new code, >> so let's fix up the code I was copying from. >> >> Signed-off-by: Eric Anholt > > Reviewed-by: Daniel Vetter Thanks! With Chris's review of 2/3, I've pushed to drm-misc-next. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 Robin changed: What|Removed |Added Summary|Rebinding AMDGPU causes |Rebinding AMDGPU causes |initialization errors [R9 |initialization errors [R9 |290 / 4.10 kernel] |290] -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #17 from Robin --- I've tested: - Disabling vfio-pci, no changes - Disabling iommu support, no changes - Booting with and without amdgpu blacklisted, no changes -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence
Up until recently sync_file were create to export a single dma-fence to
userspace, and so we could canabalise a bit insie dma-fence to mark
whether or not we had enable polling for the sync_file itself. However,
with the advent of syncobj, we do allow userspace to create multiple
sync_files for a single dma-fence. (Similarly, that the sw-sync
validation framework also started returning multiple sync-files wrapping
a single dma-fence for a syncpt also triggering the problem.)
This patch reverts my suggestion in commit e24165537312
("dma-buf/sync_file: only enable fence signalling on poll()") to use a
single bit in the shared dma-fence and restores the sync_file->flags for
tracking the bits individually.
Reported-by: Gustavo Padovan
Fixes: f1e8c67123cf ("dma-buf/sw-sync: Use an rbtree to sort fences in the
timeline")
Fixes: e9083420bbac ("drm: introduce sync objects (v4)")
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.13-rc1+
---
drivers/dma-buf/sync_file.c | 5 +++--
include/linux/sync_file.h | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index d7e219d2669d..66fb40d0ebdb 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -304,7 +304,7 @@ static int sync_file_release(struct inode *inode, struct
file *file)
{
struct sync_file *sync_file = file->private_data;
- if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
+ if (test_bit(POLL_ENABLED, &sync_file->flags))
dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
dma_fence_put(sync_file->fence);
kfree(sync_file);
@@ -318,7 +318,8 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
poll_wait(file, &sync_file->wq, wait);
- if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
+ if (list_empty(&sync_file->cb.node) &&
+ !test_and_set_bit(POLL_ENABLED, &sync_file->flags)) {
if (dma_fence_add_callback(sync_file->fence, &sync_file->cb,
fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 5726107963b2..0ad87c434ae6 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -43,12 +43,13 @@ struct sync_file {
#endif
wait_queue_head_t wq;
+ unsigned long flags;
struct dma_fence*fence;
struct dma_fence_cb cb;
};
-#define POLL_ENABLED DMA_FENCE_FLAG_USER_BITS
+#define POLL_ENABLED 0
struct sync_file *sync_file_create(struct dma_fence *fence);
struct dma_fence *sync_file_get_fence(int fd);
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #16 from Robin --- (In reply to Alex Deucher from comment #15) > Are you using a patched qemu that attempts to do radeon device specific gpu > reset? If so, does removing that code help? Next, are you sure pci config > access is allowed in your configuration? As I mentioned in comment 11, it's > required for gpu reset to work. I have installed the ubuntu supplied version. > $ kvm --version > QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3) > Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers But KVM/Qemu is not being invoked. After a fresh boot on bare metal, these are the results I get in a root TTY. I have seen mention of vfio-pci using device specific resets though. https://www.spinics.net/lists/kvm/msg116277.html So I will try to completely take it out of my test. I'm not sure about pci config access, since I don't know how to verify this. Any instructions would be appreciated. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96296] clpeak causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=96296 --- Comment #8 from Jan Vesely --- got this today. No hang. Platform: Clover Device: AMD TURKS (DRM 2.49.0 / 4.11.11-300.fc26.x86_64, LLVM 6.0.0) Driver version : 17.3.0-devel (Linux x64) Compute units : 6 Clock frequency : 650 MHz Global memory bandwidth (GBPS) float : 40.47 float2 : 41.01 float4 : 38.05 float8 : 25.09 float16 : 13.33 Single-precision compute (GFLOPS) float : 124.18 float2 : 243.14 float4 : 249.80 float8 : 285.99 float16 : 350.36 No double precision support! Skipped Integer compute (GIOPS) int : 62.25 int2 : 122.03 int4 : 123.01 int8 : 122.29 int16 : 122.11 Transfer bandwidth (GBPS) enqueueWriteBuffer : 18.15 enqueueReadBuffer : 3.06 enqueueMapBuffer(for read) : 6.53 memcpy from mapped ptr : 5.65 enqueueUnmap(after write) : 2108.68 memcpy to mapped ptr : 7.49 Kernel launch latency : 67.10 us -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #15 from Alex Deucher --- Are you using a patched qemu that attempts to do radeon device specific gpu reset? If so, does removing that code help? Next, are you sure pci config access is allowed in your configuration? As I mentioned in comment 11, it's required for gpu reset to work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #5 from Jan Vesely --- (In reply to Vedran Miletić from comment #4) > Nat, does this bug still occur? All NAS benchmarks require cl_khr_fp64, so they won't run on pre GCN hw any time soon. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #14 from Robin --- Created attachment 133108 --> https://bugs.freedesktop.org/attachment.cgi?id=133108&action=edit case3.sh So, tinkering with the test script I've only been able to eliminate some suspicions and invalidate my observation the patch performed better. I've taken out vfio-pci binding from the loop. It's only used during boot to keep the GPU free to unbind. So it's not related to vfio-pci's having access in between binds. I've made 3 methods for rebinding amdgpu. amdgpu rmmod > modprobe remove pci devices > rescan driver unbind > bind I've run each of these a few dozen times on each kernel and none of them really stand out. All of them have a chance to work (as in, ring 1 test failure only) or to fail. 4.13rc2, drm-next-4.14-wip, drm-next-4.14-wip + patch3 all have this behaviour. So no I don't think they've helped after all. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9 v2] ASoC: AMD: disabling memory gating in stoney platform
From: Vijendar Mukunda
For Stoney platform, Memory gating is disabled.i.e SRAM Banks
won't be turned off. By Default, SRAM Bank state set to ON.
Added condition checks to skip SRAM Bank state set logic for
Stoney platform.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2: Added comments in code and removed locally defined macros
for STONEY and Carrizo.
sound/soc/amd/acp-pcm-dma.c | 79 +++--
1 file changed, 55 insertions(+), 24 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index dcbf997..f00b6b9 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -20,7 +20,7 @@
#include
#include
-
+#include
#include "acp.h"
#define PLAYBACK_MIN_NUM_PERIODS2
@@ -419,7 +419,7 @@ static void acp_set_sram_bank_state(void __iomem *acp_mmio,
u16 bank,
}
/* Initialize and bring ACP hardware to default state. */
-static int acp_init(void __iomem *acp_mmio)
+static int acp_init(void __iomem *acp_mmio, u32 asic_type)
{
u16 bank;
u32 val, count, sram_pte_offset;
@@ -493,9 +493,14 @@ static int acp_init(void __iomem *acp_mmio)
/* When ACP_TILE_P1 is turned on, all SRAM banks get turned on.
* Now, turn off all of them. This can't be done in 'poweron' of
* ACP pm domain, as this requires ACP to be initialized.
+ * For Stoney, Memory gating is disabled,i.e SRAM Banks
+ * won't be turned off. The default state for SRAM banks is ON.
+ * Setting SRAM bank state code skipped for STONEY platform.
*/
- for (bank = 1; bank < 48; bank++)
- acp_set_sram_bank_state(acp_mmio, bank, false);
+ if (asic_type != CHIP_STONEY) {
+ for (bank = 1; bank < 48; bank++)
+ acp_set_sram_bank_state(acp_mmio, bank, false);
+ }
return 0;
}
@@ -646,14 +651,22 @@ static int acp_dma_open(struct snd_pcm_substream
*substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
intr_data->play_stream = substream;
- for (bank = 1; bank <= 4; bank++)
- acp_set_sram_bank_state(intr_data->acp_mmio, bank,
- true);
+ /* For Stoney, Memory gating is disabled,i.e SRAM Banks
+* won't be turned off. The default state for SRAM banks is ON.
+* Setting SRAM bank state code skipped for STONEY platform.
+*/
+ if (intr_data->asic_type != CHIP_STONEY) {
+ for (bank = 1; bank <= 4; bank++)
+ acp_set_sram_bank_state(intr_data->acp_mmio,
+ bank, true);
+ }
} else {
intr_data->capture_stream = substream;
- for (bank = 5; bank <= 8; bank++)
- acp_set_sram_bank_state(intr_data->acp_mmio, bank,
- true);
+ if (intr_data->asic_type != CHIP_STONEY) {
+ for (bank = 5; bank <= 8; bank++)
+ acp_set_sram_bank_state(intr_data->acp_mmio,
+ bank, true);
+ }
}
return 0;
@@ -869,14 +882,23 @@ static int acp_dma_close(struct snd_pcm_substream
*substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
adata->play_stream = NULL;
- for (bank = 1; bank <= 4; bank++)
- acp_set_sram_bank_state(adata->acp_mmio, bank,
- false);
- } else {
+ /* For Stoney, Memory gating is disabled,i.e SRAM Banks
+* won't be turned off. The default state for SRAM banks is ON.
+* Setting SRAM bank state code skipped for STONEY platform.
+* added condition checks for Carrizo platform only
+*/
+ if (adata->asic_type != CHIP_STONEY) {
+ for (bank = 1; bank <= 4; bank++)
+ acp_set_sram_bank_state(adata->acp_mmio, bank,
+ false);
+ }
+ } else {
adata->capture_stream = NULL;
- for (bank = 5; bank <= 8; bank++)
- acp_set_sram_bank_state(adata->acp_mmio, bank,
- false);
+ if (adata->asic_type != CHIP_STONEY) {
+ for (bank = 5; bank <= 8; bank++)
+ acp_set_sram_bank_state(adata->acp_mmio, bank,
+false);
+ }
}
/* Disable ACP irq, when the current stream is being closed and
@@ -945,7 +967,7 @@ static int acp_audio_probe(struct platform_device
[PATCH 8/9 v2] drm/amd/amdgpu: Disabling Power Gating for Stoney platform
From: Vijendar Mukunda
Power Gating is disabled in Stoney platform.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2: added missing changes required for power gating and
removed local variable.
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 51 ++---
1 file changed, 28 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index 9c0bd6c..ebca223 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -285,19 +285,20 @@ static int acp_hw_init(void *handle)
return 0;
else if (r)
return r;
+ if (adev->asic_type != CHIP_STONEY) {
+ adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_domain),
GFP_KERNEL);
+ if (adev->acp.acp_genpd == NULL)
+ return -ENOMEM;
- adev->acp.acp_genpd = kzalloc(sizeof(struct acp_pm_domain), GFP_KERNEL);
- if (adev->acp.acp_genpd == NULL)
- return -ENOMEM;
-
- adev->acp.acp_genpd->gpd.name = "ACP_AUDIO";
- adev->acp.acp_genpd->gpd.power_off = acp_poweroff;
- adev->acp.acp_genpd->gpd.power_on = acp_poweron;
+ adev->acp.acp_genpd->gpd.name = "ACP_AUDIO";
+ adev->acp.acp_genpd->gpd.power_off = acp_poweroff;
+ adev->acp.acp_genpd->gpd.power_on = acp_poweron;
- adev->acp.acp_genpd->cgs_dev = adev->acp.cgs_device;
+ adev->acp.acp_genpd->cgs_dev = adev->acp.cgs_device;
- pm_genpd_init(&adev->acp.acp_genpd->gpd, NULL, false);
+ pm_genpd_init(&adev->acp.acp_genpd->gpd, NULL, false);
+ }
adev->acp.acp_cell = kzalloc(sizeof(struct mfd_cell) * ACP_DEVS,
GFP_KERNEL);
@@ -390,12 +391,14 @@ static int acp_hw_init(void *handle)
if (r)
return r;
- for (i = 0; i < ACP_DEVS ; i++) {
- dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
- r = pm_genpd_add_device(&adev->acp.acp_genpd->gpd, dev);
- if (r) {
- dev_err(dev, "Failed to add dev to genpd\n");
- return r;
+ if (adev->asic_type != CHIP_STONEY) {
+ for (i = 0; i < ACP_DEVS ; i++) {
+ dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
+ r = pm_genpd_add_device(&adev->acp.acp_genpd->gpd, dev);
+ if (r) {
+ dev_err(dev, "Failed to add dev to genpd\n");
+ return r;
+ }
}
}
@@ -415,20 +418,22 @@ static int acp_hw_fini(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
/* return early if no ACP */
- if (!adev->acp.acp_genpd)
+ if (!adev->acp.acp_cell)
return 0;
- for (i = 0; i < ACP_DEVS ; i++) {
- dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
- ret = pm_genpd_remove_device(&adev->acp.acp_genpd->gpd, dev);
- /* If removal fails, dont giveup and try rest */
- if (ret)
- dev_err(dev, "remove dev from genpd failed\n");
+ if (adev->acp.acp_genpd) {
+ for (i = 0; i < ACP_DEVS ; i++) {
+ dev = get_mfd_cell_dev(adev->acp.acp_cell[i].name, i);
+ ret = pm_genpd_remove_device(&adev->acp.acp_genpd->gpd,
dev);
+ /* If removal fails, dont giveup and try rest */
+ if (ret)
+ dev_err(dev, "remove dev from genpd failed\n");
+ }
+ kfree(adev->acp.acp_genpd);
}
mfd_remove_devices(adev->acp.parent);
kfree(adev->acp.acp_res);
- kfree(adev->acp.acp_genpd);
kfree(adev->acp.acp_cell);
return 0;
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9 v2] ASoC: AMD: Add machine driver for cz rt5650
From: Akshu Agrawal
The driver is used for AMD board using rt5650 codec.
Signed-off-by: Akshu Agrawal
Signed-off-by: Alex Deucher
---
V2: Change ACPI ID to AMDI1002
sound/soc/amd/Kconfig | 7 ++
sound/soc/amd/Makefile | 2 +
sound/soc/amd/acp-rt5645.c | 210 +
3 files changed, 219 insertions(+)
create mode 100644 sound/soc/amd/acp-rt5645.c
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index 78187eb..eb0ae60 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -2,3 +2,10 @@ config SND_SOC_AMD_ACP
tristate "AMD Audio Coprocessor support"
help
This option enables ACP DMA support on AMD platform.
+config SND_SOC_AMD_CZ_RT5645_MACH
+ tristate "AMD CZ support for RT5645"
+ select SND_SOC_RT5645
+ select SND_SOC_AMD_ACP
+ depends on I2C_DESIGNWARE_PLATFORM
+ help
+This option enables machine driver for rt5645.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index 1a66ec0..eed64ff 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,3 +1,5 @@
snd-soc-acp-pcm-objs := acp-pcm-dma.o
+snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-rt5645.c b/sound/soc/amd/acp-rt5645.c
new file mode 100644
index 000..a17dbea
--- /dev/null
+++ b/sound/soc/amd/acp-rt5645.c
@@ -0,0 +1,210 @@
+/*
+ * Machine driver for AMD ACP Audio engine using Realtek RT5645 codec
+ *
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * This file is modified from rt288 machine driver
+ *
+ * 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 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) OR AUTHOR(S) 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.
+ *
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../codecs/rt5645.h"
+
+#define CZ_PLAT_CLK 2400
+
+static struct snd_soc_jack cz_jack;
+
+static int cz_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ int ret = 0;
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+
+ ret = snd_soc_dai_set_pll(codec_dai, 0, RT5645_PLL1_S_MCLK,
+ CZ_PLAT_CLK, params_rate(params) * 512);
+ if (ret < 0) {
+ dev_err(rtd->dev, "can't set codec pll: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_sysclk(codec_dai, RT5645_SCLK_S_PLL1,
+ params_rate(params) * 512, SND_SOC_CLOCK_OUT);
+ if (ret < 0) {
+ dev_err(rtd->dev, "can't set codec sysclk: %d\n", ret);
+ return ret;
+ }
+
+ return ret;
+}
+
+static int cz_init(struct snd_soc_pcm_runtime *rtd)
+{
+ int ret;
+ struct snd_soc_card *card;
+ struct snd_soc_codec *codec;
+
+ codec = rtd->codec;
+ card = rtd->card;
+
+ ret = snd_soc_card_jack_new(card, "Headset Jack",
+ SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
+ SND_JACK_BTN_0 | SND_JACK_BTN_1 |
+ SND_JACK_BTN_2 | SND_JACK_BTN_3,
+ &cz_jack, NULL, 0);
+ if (ret) {
+ dev_err(card->dev, "HP jack creation failed %d\n", ret);
+ return ret;
+ }
+
+ rt5645_set_jack_detect(codec, &cz_jack, &cz_jack, &cz_jack);
+
+ return 0;
+}
+
+static struct snd_soc_ops cz_aif1_ops = {
+ .hw_params = cz_aif1_hw_params,
+};
+
+static struct snd_soc_dai_link cz_dai_rt5650[] = {
+ {
+ .name = "amd-rt5645-play",
+ .stream_name = "RT5645_AIF1",
+ .platform_name = "acp_audio_dma.0.auto",
+ .cpu_dai_name = "designware-i2s.1.auto",
+
[PATCH 7/9 v2] ASoC: AMD: Audio buffer related changes for Stoney
From: Vijendar Mukunda
Stoney uses 16kb SRAM memory for playback and 16Kb
for capture.Modified Max buffer size to have the
correct mapping between System Memory and SRAM.
Added snd_pcm_hardware structures for playback
and capture for Stoney.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2: Added switch cases for asic type.
sound/soc/amd/acp-pcm-dma.c | 73 +
1 file changed, 68 insertions(+), 5 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f16e0b8..a6def3b 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -35,6 +35,10 @@
#define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
#define MIN_BUFFER MAX_BUFFER
+#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
+#define ST_CAPTURE_MAX_PERIOD_SIZE 8192
+#define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define ST_MIN_BUFFER ST_MAX_BUFFER
static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -73,6 +77,44 @@ static const struct snd_pcm_hardware
acp_pcm_hardware_capture = {
.periods_max = CAPTURE_MAX_NUM_PERIODS,
};
+static const struct snd_pcm_hardware acp_st_pcm_hardware_playback = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+ .channels_min = 1,
+ .channels_max = 8,
+ .rates = SNDRV_PCM_RATE_8000_96000,
+ .rate_min = 8000,
+ .rate_max = 96000,
+ .buffer_bytes_max = ST_MAX_BUFFER,
+ .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
+ .period_bytes_max = ST_PLAYBACK_MAX_PERIOD_SIZE,
+ .periods_min = PLAYBACK_MIN_NUM_PERIODS,
+ .periods_max = PLAYBACK_MAX_NUM_PERIODS,
+};
+
+static const struct snd_pcm_hardware acp_st_pcm_hardware_capture = {
+ .info = SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_48000,
+ .rate_min = 8000,
+ .rate_max = 48000,
+ .buffer_bytes_max = ST_MAX_BUFFER,
+ .period_bytes_min = CAPTURE_MIN_PERIOD_SIZE,
+ .period_bytes_max = ST_CAPTURE_MAX_PERIOD_SIZE,
+ .periods_min = CAPTURE_MIN_NUM_PERIODS,
+ .periods_max = CAPTURE_MAX_NUM_PERIODS,
+};
+
static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
{
return readl(acp_mmio + (reg * 4));
@@ -664,10 +706,23 @@ static int acp_dma_open(struct snd_pcm_substream
*substream)
if (adata == NULL)
return -ENOMEM;
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- runtime->hw = acp_pcm_hardware_playback;
- else
- runtime->hw = acp_pcm_hardware_capture;
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ switch (intr_data->asic_type) {
+ case CHIP_STONEY:
+ runtime->hw = acp_st_pcm_hardware_playback;
+ break;
+ default:
+ runtime->hw = acp_pcm_hardware_playback;
+ }
+ } else {
+ switch (intr_data->asic_type) {
+ case CHIP_STONEY:
+ runtime->hw = acp_st_pcm_hardware_capture;
+ break;
+ default:
+ runtime->hw = acp_pcm_hardware_capture;
+ }
+ }
ret = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS);
@@ -905,7 +960,15 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
static int acp_dma_new(struct snd_soc_pcm_runtime *rtd)
{
- return snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,
+ struct audio_drv_data *adata = dev_get_drvdata(rtd->platform->dev);
+
+ if (adata->asic_type == CHIP_STONEY)
+ return snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,
+ SNDRV_DMA_TYPE_DEV,
+ NULL, ST_MIN_BUFFER,
+ ST_MAX_BUFFER);
+ else
+ return snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,
SNDRV_DMA_TYPE_DEV,
[PATCH 2/9 v2] drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
From: Vijendar Mukunda
asic_type information is passed to ACP DMA Driver as platform data.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2:Removed asic_type local variable and directly passing asic_type
instance to ACP DMA driver as platform data.
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 2 ++
sound/soc/amd/acp-pcm-dma.c | 8 ++--
sound/soc/amd/acp.h | 7 +++
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index 06879d1..0fa8122 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -355,6 +355,8 @@ static int acp_hw_init(void *handle)
adev->acp.acp_cell[0].name = "acp_audio_dma";
adev->acp.acp_cell[0].num_resources = 4;
adev->acp.acp_cell[0].resources = &adev->acp.acp_res[0];
+ adev->acp.acp_cell[0].platform_data = &adev->asic_type;
+ adev->acp.acp_cell[0].pdata_size = sizeof(adev->asic_type);
adev->acp.acp_cell[1].name = "designware-i2s";
adev->acp.acp_cell[1].num_resources = 1;
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 08b1399..dcbf997 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -73,12 +73,6 @@ static const struct snd_pcm_hardware
acp_pcm_hardware_capture = {
.periods_max = CAPTURE_MAX_NUM_PERIODS,
};
-struct audio_drv_data {
- struct snd_pcm_substream *play_stream;
- struct snd_pcm_substream *capture_stream;
- void __iomem *acp_mmio;
-};
-
static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
{
return readl(acp_mmio + (reg * 4));
@@ -916,6 +910,7 @@ static int acp_audio_probe(struct platform_device *pdev)
int status;
struct audio_drv_data *audio_drv_data;
struct resource *res;
+ const u32 *pdata = pdev->dev.platform_data;
audio_drv_data = devm_kzalloc(&pdev->dev, sizeof(struct audio_drv_data),
GFP_KERNEL);
@@ -932,6 +927,7 @@ static int acp_audio_probe(struct platform_device *pdev)
audio_drv_data->play_stream = NULL;
audio_drv_data->capture_stream = NULL;
+ audio_drv_data->asic_type = *pdata;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 330832e..28cf914 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -84,6 +84,13 @@ struct audio_substream_data {
void __iomem *acp_mmio;
};
+struct audio_drv_data {
+ struct snd_pcm_substream *play_stream;
+ struct snd_pcm_substream *capture_stream;
+ void __iomem *acp_mmio;
+ u32 asic_type;
+};
+
enum {
ACP_TILE_P1 = 0,
ACP_TILE_P2,
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/amdgpu Moving amdgpu asic types to a separate file
From: Akshu Agrawal
Amdgpu asic types will be required for other drivers too.
Hence, its better to keep it in a separate include file.
Signed-off-by: Akshu Agrawal
Signed-off-by: Alex Deucher
---
New patch to share asic_type definitions between GPU and audio driver.
drivers/gpu/drm/amd/include/amd_shared.h | 29 ++
include/drm/amd_asic_type.h | 52
2 files changed, 54 insertions(+), 27 deletions(-)
create mode 100644 include/drm/amd_asic_type.h
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 70e8c20..3a49fbd 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -23,34 +23,9 @@
#ifndef __AMD_SHARED_H__
#define __AMD_SHARED_H__
-#define AMD_MAX_USEC_TIMEOUT 20 /* 200 ms */
+#include
-/*
- * Supported ASIC types
- */
-enum amd_asic_type {
- CHIP_TAHITI = 0,
- CHIP_PITCAIRN,
- CHIP_VERDE,
- CHIP_OLAND,
- CHIP_HAINAN,
- CHIP_BONAIRE,
- CHIP_KAVERI,
- CHIP_KABINI,
- CHIP_HAWAII,
- CHIP_MULLINS,
- CHIP_TOPAZ,
- CHIP_TONGA,
- CHIP_FIJI,
- CHIP_CARRIZO,
- CHIP_STONEY,
- CHIP_POLARIS10,
- CHIP_POLARIS11,
- CHIP_POLARIS12,
- CHIP_VEGA10,
- CHIP_RAVEN,
- CHIP_LAST,
-};
+#define AMD_MAX_USEC_TIMEOUT 20 /* 200 ms */
/*
* Chip flags
diff --git a/include/drm/amd_asic_type.h b/include/drm/amd_asic_type.h
new file mode 100644
index 000..599028f
--- /dev/null
+++ b/include/drm/amd_asic_type.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2017 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 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) OR AUTHOR(S) 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.
+ */
+
+#ifndef __AMD_ASIC_TYPE_H__
+#define __AMD_ASIC_TYPE_H__
+/*
+ * Supported ASIC types
+ */
+enum amd_asic_type {
+ CHIP_TAHITI = 0,
+ CHIP_PITCAIRN,
+ CHIP_VERDE,
+ CHIP_OLAND,
+ CHIP_HAINAN,
+ CHIP_BONAIRE,
+ CHIP_KAVERI,
+ CHIP_KABINI,
+ CHIP_HAWAII,
+ CHIP_MULLINS,
+ CHIP_TOPAZ,
+ CHIP_TONGA,
+ CHIP_FIJI,
+ CHIP_CARRIZO,
+ CHIP_STONEY,
+ CHIP_POLARIS10,
+ CHIP_POLARIS11,
+ CHIP_POLARIS12,
+ CHIP_VEGA10,
+ CHIP_RAVEN,
+ CHIP_LAST,
+};
+
+#endif /*__AMD_ASIC_TYPE_H__ */
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9 v2] ASoC: AMD: DMA driver changes for Stoney Platform
From: Vijendar Mukunda
Added DMA driver changes for Stoney platform.
Below are the key differences between Stoney and CZ
In Stoney, Memory Gating is disabled.SRAM Banks won't
be turned off.No Of SRAM Banks reduced to 6.
DAGB Garlic Interface used and 16 bit resolution is supported.
SRAM bank 1 & SRAM bank 2 will be used for playback scenario.
SRAM Bank 3 & SRAM Bank 4 will be used for Capture scenario.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2: Added switch cases for asic type.
sound/soc/amd/acp-pcm-dma.c | 87 +
sound/soc/amd/acp.h | 2 ++
2 files changed, 67 insertions(+), 22 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f00b6b9..f16e0b8 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -137,8 +137,8 @@ static void config_dma_descriptor_in_sram(void __iomem
*acp_mmio,
* system memory <-> ACP SRAM
*/
static void set_acp_sysmem_dma_descriptors(void __iomem *acp_mmio,
- u32 size, int direction,
- u32 pte_offset)
+ u32 size, int direction,
+ u32 pte_offset, u32 asic_type)
{
u16 i;
u16 dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
@@ -152,20 +152,42 @@ static void set_acp_sysmem_dma_descriptors(void __iomem
*acp_mmio,
(size / 2) - (i * (size/2));
dmadscr[i].src = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
+ (pte_offset * SZ_4K) + (i * (size/2));
- dmadscr[i].xfer_val |=
- (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM << 16) |
- (size / 2);
+ switch (asic_type) {
+ case CHIP_STONEY:
+ dmadscr[i].xfer_val |=
+ (ACP_DMA_ATTRIBUTES_DAGB_GARLIC_TO_SHAREDMEM
<< 16) |
+ (size / 2);
+ break;
+ default:
+ dmadscr[i].xfer_val |=
+ (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM <<
16) |
+ (size / 2);
+ }
} else {
dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14 + i;
- dmadscr[i].src = ACP_SHARED_RAM_BANK_5_ADDRESS +
- (i * (size/2));
- dmadscr[i].dest = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
- + (pte_offset * SZ_4K) +
- (i * (size/2));
- dmadscr[i].xfer_val |=
- BIT(22) |
- (ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION << 16) |
- (size / 2);
+ switch (asic_type) {
+ case CHIP_STONEY:
+ dmadscr[i].src = ACP_SHARED_RAM_BANK_3_ADDRESS +
+ (i * (size/2));
+ dmadscr[i].dest =
+ ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+ (pte_offset * SZ_4K) + (i * (size/2));
+ dmadscr[i].xfer_val |=
+ BIT(22) |
+ (ACP_DMA_ATTRIBUTES_SHARED_MEM_TO_DAGB_GARLIC
<< 16) |
+ (size / 2);
+ break;
+ default:
+ dmadscr[i].src = ACP_SHARED_RAM_BANK_5_ADDRESS +
+ (i * (size/2));
+ dmadscr[i].dest =
+ ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+ (pte_offset * SZ_4K) + (i * (size/2));
+ dmadscr[i].xfer_val |=
+ BIT(22) |
+ (ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION <<
16) |
+ (size / 2);
+ }
}
config_dma_descriptor_in_sram(acp_mmio, dma_dscr_idx,
&dmadscr[i]);
@@ -186,7 +208,8 @@ static void set_acp_sysmem_dma_descriptors(void __iomem
*acp_mmio,
* ACP SRAM <-> I2S
*/
static void set_acp_to_i2s_dma_descriptors(void __iomem *acp_mmio,
- u32 size, int direction)
+ u32 size, int direction,
+ u32 asic_type)
{
u16 i;
@@ -207,8 +230,17 @@ static void set_acp_to_i2s_dma_descriptors(void __iomem
*acp_mmio,
dma_ds
[PATCH 0/9 v2] Add ASoC support for AMD Stoney APUs
This patch set updates the AMD GPU and Audio CoProcessor (ACP) audio drivers and the designware i2s driver for Stoney (ST). ST is an APU similar to Carrizo (CZ) which already has ACP audio support. The i2s controller and ACP audio DMA engine are part of the GPU and both need updating so I would like to upstream the whole patch set via one tree if possible. The current code is based on drm-next, but I'm happy to rebase on whatever tree this ends up going through if there are any problems applying. The entire patch set can be viewed here: https://cgit.freedesktop.org/~agd5f/linux/log/?h=stoney_acp Thanks! Alex v2: - Patch 1 is already applied to the audio tree, just including it for completeness since it's required for this patch set and it's not yet in the drm tree. - New patch to share asic types between gpu and audio drivers - ACPI ID changed for rt5650 machine driver - Integrate feedback on other patches Akshu Agrawal (2): drm/amdgpu Moving amdgpu asic types to a separate file ASoC: AMD: Add machine driver for cz rt5650 Vijendar Mukunda (7): ASoC: dwc: Added a quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to dwc driver drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data drm/amd/amdgpu: Added a quirk for Stoney platform ASoC: AMD: disabling memory gating in stoney platform ASoC: AMD: DMA driver changes for Stoney Platform ASoC: AMD: Audio buffer related changes for Stoney drm/amd/amdgpu: Disabling Power Gating for Stoney platform drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 74 ++ drivers/gpu/drm/amd/include/amd_shared.h | 29 +--- include/drm/amd_asic_type.h | 52 +++ include/sound/designware_i2s.h | 1 + sound/soc/amd/Kconfig| 7 + sound/soc/amd/Makefile | 2 + sound/soc/amd/acp-pcm-dma.c | 243 --- sound/soc/amd/acp-rt5645.c | 210 ++ sound/soc/amd/acp.h | 9 ++ sound/soc/dwc/dwc-i2s.c | 6 + 10 files changed, 525 insertions(+), 108 deletions(-) create mode 100644 include/drm/amd_asic_type.h create mode 100644 sound/soc/amd/acp-rt5645.c -- 2.5.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] ASoC: dwc: Added a quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to dwc driver
From: Vijendar Mukunda
Added quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to Designware
driver. This quirk will set idx value to 1.
By setting this quirk, it will override supported format
as 16 bit resolution and bus width as 2 Bytes.
Reviewed-by: Alex Deucher
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
This patch is already applied to the audio tree, I'm just
including it here for completeness since it's not yet in
the drm tree.
include/sound/designware_i2s.h | 1 +
sound/soc/dwc/dwc-i2s.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/include/sound/designware_i2s.h b/include/sound/designware_i2s.h
index 5681855..830f5ca 100644
--- a/include/sound/designware_i2s.h
+++ b/include/sound/designware_i2s.h
@@ -47,6 +47,7 @@ struct i2s_platform_data {
#define DW_I2S_QUIRK_COMP_REG_OFFSET(1 << 0)
#define DW_I2S_QUIRK_COMP_PARAM1(1 << 1)
+ #define DW_I2S_QUIRK_16BIT_IDX_OVERRIDE (1 << 2)
unsigned int quirks;
unsigned int i2s_reg_comp1;
unsigned int i2s_reg_comp2;
diff --git a/sound/soc/dwc/dwc-i2s.c b/sound/soc/dwc/dwc-i2s.c
index 9c46e41..9160676 100644
--- a/sound/soc/dwc/dwc-i2s.c
+++ b/sound/soc/dwc/dwc-i2s.c
@@ -496,6 +496,8 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
idx = COMP1_TX_WORDSIZE_0(comp1);
if (WARN_ON(idx >= ARRAY_SIZE(formats)))
return -EINVAL;
+ if (dev->quirks & DW_I2S_QUIRK_16BIT_IDX_OVERRIDE)
+ idx = 1;
dw_i2s_dai->playback.channels_min = MIN_CHANNEL_NUM;
dw_i2s_dai->playback.channels_max =
1 << (COMP1_TX_CHANNELS(comp1) + 1);
@@ -508,6 +510,8 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
idx = COMP2_RX_WORDSIZE_0(comp2);
if (WARN_ON(idx >= ARRAY_SIZE(formats)))
return -EINVAL;
+ if (dev->quirks & DW_I2S_QUIRK_16BIT_IDX_OVERRIDE)
+ idx = 1;
dw_i2s_dai->capture.channels_min = MIN_CHANNEL_NUM;
dw_i2s_dai->capture.channels_max =
1 << (COMP1_RX_CHANNELS(comp1) + 1);
@@ -543,6 +547,8 @@ static int dw_configure_dai_by_pd(struct dw_i2s_dev *dev,
if (ret < 0)
return ret;
+ if (dev->quirks & DW_I2S_QUIRK_16BIT_IDX_OVERRIDE)
+ idx = 1;
/* Set DMA slaves info */
dev->play_dma_data.pd.data = pdata->play_dma_data;
dev->capture_dma_data.pd.data = pdata->capture_dma_data;
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9 v2] drm/amd/amdgpu: Added a quirk for Stoney platform
From: Vijendar Mukunda
Added DW_I2S_QUIRK_16BIT_IDX_OVERRIDE quirk for Stoney.
Supported format and bus width for I2S controller read
from I2S Component Parameter registers.
These are ready only registers.
For Stoney, I2S Component Parameter registers are programmed
to support 32 bit format and 4 bytes bus width only.
By setting this quirk,It will override 32 bit format with
16 bit format and 2 bytes as bus width for Stoney.
Signed-off-by: Vijendar Mukunda
Signed-off-by: Alex Deucher
---
v2: added switch cases for handling asic types.
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index 0fa8122..9c0bd6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -319,14 +319,29 @@ static int acp_hw_init(void *handle)
return -ENOMEM;
}
- i2s_pdata[0].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET;
+ switch (adev->asic_type) {
+ case CHIP_STONEY:
+ i2s_pdata[0].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET |
+ DW_I2S_QUIRK_16BIT_IDX_OVERRIDE;
+ break;
+ default:
+ i2s_pdata[0].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET;
+ }
i2s_pdata[0].cap = DWC_I2S_PLAY;
i2s_pdata[0].snd_rates = SNDRV_PCM_RATE_8000_96000;
i2s_pdata[0].i2s_reg_comp1 = ACP_I2S_COMP1_PLAY_REG_OFFSET;
i2s_pdata[0].i2s_reg_comp2 = ACP_I2S_COMP2_PLAY_REG_OFFSET;
+ switch (adev->asic_type) {
+ case CHIP_STONEY:
+ i2s_pdata[1].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET |
+ DW_I2S_QUIRK_COMP_PARAM1 |
+ DW_I2S_QUIRK_16BIT_IDX_OVERRIDE;
+ break;
+ default:
+ i2s_pdata[1].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET |
+ DW_I2S_QUIRK_COMP_PARAM1;
+ }
- i2s_pdata[1].quirks = DW_I2S_QUIRK_COMP_REG_OFFSET |
- DW_I2S_QUIRK_COMP_PARAM1;
i2s_pdata[1].cap = DWC_I2S_RECORD;
i2s_pdata[1].snd_rates = SNDRV_PCM_RATE_8000_96000;
i2s_pdata[1].i2s_reg_comp1 = ACP_I2S_COMP1_CAP_REG_OFFSET;
--
2.5.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats
Quoting Eric Anholt (2017-07-25 19:27:25)
> Chris Wilson writes:
>
> > Quoting Eric Anholt (2017-06-22 21:50:54)
> >> This has proven immensely useful for debugging memory leaks and
> >> overallocation (which is a rather serious concern on the platform,
> >> given that we typically run at about 256MB of CMA out of up to 1GB
> >> total memory, with framebuffers that are about 8MB ecah).
> >>
> >> The state of the art without this is to dump debug logs from every GL
> >> application, guess as to kernel allocations based on bo_stats, and try
> >> to merge that all together into a global picture of memory allocation
> >> state. With this, you can add a couple of calls to the debug build of
> >> the 3D driver and get a pretty detailed view of GPU memory usage from
> >> /debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
> >> failure).
> >>
> >> The Mesa side currently labels at the gallium resource level (so you
> >> see that a 1920x20 pixmap has been created, presumably for the window
> >> system panel), but we could extend that to be even more useful with
> >> glObjectLabel() names being sent all the way down to the kernel.
> >>
> >> (partial) example of sorted debugfs output with Mesa labeling all
> >> resources:
> >>
> >>kernel BO cache: 16392kb BOs (3)
> >>tiling shadow 1920x1080: 8160kb BOs (1)
> >>resource 1920x1080@32/0: 8160kb BOs (1)
> >> scanout resource 1920x1080@32/0: 8100kb BOs (1)
> >> kernel: 8100kb BOs (1)
> >>
> >> Signed-off-by: Eric Anholt
> >> ---
> >
> >> static void vc4_bo_stats_dump(struct vc4_dev *vc4)
> >> {
> >
> > Now unused?
>
> Still used from the splat when CMA allocation fails. It's less
> catastrophic than it used to be, but still bad, so we're dumping to
> dmesg for now.
>
> >> - DRM_INFO("num bos allocated: %d\n",
> >> -vc4->bo_stats.num_allocated);
> >> - DRM_INFO("size bos allocated: %dkb\n",
> >> -vc4->bo_stats.size_allocated / 1024);
> >> - DRM_INFO("num bos used: %d\n",
> >> -vc4->bo_stats.num_allocated - vc4->bo_stats.num_cached);
> >> - DRM_INFO("size bos used: %dkb\n",
> >> -(vc4->bo_stats.size_allocated -
> >> - vc4->bo_stats.size_cached) / 1024);
> >> - DRM_INFO("num bos cached: %d\n",
> >> -vc4->bo_stats.num_cached);
> >> - DRM_INFO("size bos cached: %dkb\n",
> >> -vc4->bo_stats.size_cached / 1024);
> >> + int i;
> >> +
> >> + for (i = 0; i < vc4->num_labels; i++) {
> >> + if (!vc4->bo_labels[i].num_allocated)
> >> + continue;
> >> +
> >> + DRM_INFO("%30s: %6dkb BOs (%d)\n",
> >> +vc4->bo_labels[i].name,
> >> +vc4->bo_labels[i].size_allocated / 1024,
> >> +vc4->bo_labels[i].num_allocated);
> >> + }
> >> }
> >>
> >> #ifdef CONFIG_DEBUG_FS
> >
> >> +/* Must be called with bo_lock held. */
> >> +static void vc4_bo_set_label(struct drm_gem_object *gem_obj, int label)
> >> +{
> >> + struct vc4_bo *bo = to_vc4_bo(gem_obj);
> >> + struct vc4_dev *vc4 = to_vc4_dev(gem_obj->dev);
> >
> > lockdep_assert_held(&vc4->bo_lock);
>
> Nice. I've converted the other instances of this comment, too.
>
> >> +
> >> + vc4->bo_labels[label].num_allocated++;
> >> + vc4->bo_labels[label].size_allocated += gem_obj->size;
> >
> > This gets called with label=-1 on destroy.
>
> Oh, good catch, thanks. This code got reworked a couple of times and I
> lost that check.
>
> >> + vc4->bo_labels[bo->label].num_allocated--;
> >> + vc4->bo_labels[bo->label].size_allocated -= gem_obj->size;
> >
> > Ok, preassigned to TYPE_KERNEL on creation.
> >
> >> + if (vc4->bo_labels[bo->label].num_allocated == 0 &&
> >> + is_user_label(bo->label)) {
> >> + /* Free user BO label slots on last unreference. */
> >> + kfree(vc4->bo_labels[bo->label].name);
> >> + vc4->bo_labels[bo->label].name = NULL;
> >> + }
> >
> > This seems dubious. As a user I would expect the label I created to last
> > until I closed the fd. Otherwise if I ever close all bo of one type,
> > wait a few seconds for the cache to be reaped, then reallocate a new bo,
> > someone else may have assigned my label a new name.
> >
> > If that's guarded against, a comment would help.
>
> Userspace can't see the label index, though, and can only set string
> names on BOs. New text:
>
> /* Free user BO label slots on last unreference.
> * Slots are just where we track the stats for a given
> * name, and once a name is unused we can reuse that
> * slot.
> */
Ah. My mistake was in thinking that you passed the name_id to the create
ioctl, but names are assigned to the bo themselves, and so
RE: [PATCH] drm/amd/powerplay: rv: Use designated initializers
> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of
> Kees Cook
> Sent: Friday, July 28, 2017 1:16 PM
> To: Alex Deucher
> Cc: LKML; David Airlie; amd-gfx list; Maling list - DRI developers; Deucher,
> Alexander; Zhu, Rex; Koenig, Christian; Zhang, Hawking
> Subject: Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers
>
> On Thu, Jul 27, 2017 at 6:43 PM, Alex Deucher
> wrote:
> > On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook
> wrote:
> >> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
> >> designated initializers") mark other tableFunction entries with designated
> >> initializers. The randstruct plugin requires designated initializers for
> >> structures that are entirely function pointers.
> >>
> >> Cc: Rex Zhu
> >> Cc: Hawking Zhang
> >> Cc: Alex Deucher
> >> Signed-off-by: Kees Cook
> >> ---
> >> If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
> >> you think this is worth landing for v4.13, in which case, please take it
> >> now. :)
> >>
> >
> > Acked-by: Alex Deucher
> >
> > I'm happy to take this through my tree if that is ok with you.
>
> Since the randstruct patch depends on this fix, it's likely best to go
> through my tree unless you can get this into v4.13. (Since then when
> the randstruct patch lands in v4.14, it'll already be there.) I'm fine
> either way.
Go ahead and take it through your tree. Thanks!
Alex
>
> Thanks!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #13 from Robin --- (In reply to Alex Deucher from comment #11) > Note that the GPU reset in patch 3/2 requires access to pci config registers > for the GPU which many hypervisors block, so you'd need to make sure that > works for the reset to work. I'm not actually utilizing vfio-pci in these test cases, this runs as root from a TTY on the host machine. So I would assume it to work. I don't know how I would test this though, let me know how I could test this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #12 from Robin --- Created attachment 133103 --> https://bugs.freedesktop.org/attachment.cgi?id=133103&action=edit case2-rescan-amd.sh In an attempt to make a second test case I've created a new script that produced some noteworthy results. Rather than bind/unbind, this approach uses rmmod,modprobe, removing the pci device and rescanning to switch drivers. Please excuse how poorly written and contrived the test case for "hotswapping" proposes, I'll try isolating what causes the differences with the first test case in some mutations next, but wanted to share the intermediate results as-is first. Some details about this test. The starting point is the same as the other test case, TTY and vfio-pci taking the card first. In order it will: 1. rmmod the current driver. 2. remove one pci subdevice (either VGA or Audio) 3. modprobe the new driver. 4. perform a pci rescan. It will do this in a loop switching between amdgpu and vfio-pci again. Another difference is that snd_hda_intel is in use elsewhere, it does not get an rmmod and will not switch back to vfio-pci because of this. --- As for results, on 4.10 there was no change. >From the 2nd binding onward this error will fail to init the driver. > [ 160.013733] [drm:ci_dpm_enable [amdgpu]] *ERROR* ci_start_dpm failed > [ 160.014134] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block > failed -22 For 4.13rc2, drm-next-4.14-wip and drm-next-4.14-wip with patch 3 it's a different story. They have an irregular pattern of errors every loop. Either the 2nd or 3rd time the first error crops up. Typically this is: > [ 211.818341] [drm:cik_sdma_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 9 > test failed (0xCAFEDEAD) > [ 211.818725] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block > failed -22 After that first error, additionally the following error can appear as well. > [ 247.626839] [drm:gfx_v7_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 1 > test failed (scratch(0xC040)=0xCAFEDEAD) And instead of ring 9, ring 10 may fail. > [ 356.686092] [drm:cik_sdma_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 10 > test failed (0xCAFEDEAD) > [ 356.686580] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block > failed -22 They seem to randomly happen in the following combinations: A. Ring 1 fails. B. Ring 9 or 10 fails. C. Ring 1 + Ring 9 or 10 fails. Most importantly though. Only if 9 or 10 fail (B or C combinations) will the hw_init error occur. If it's just a ring 1 failure (A) the driver will successfully init the GPU. Also, the drm-next-4.14-wip with patch 3 kernel will have this A combination and successful init a lot more often that the other two. --- So my suspicion is that this difference could be due to: - Repeatedly rmmodding and modprobing being part of the loop now. - The rescanning method vs bind/unbind. - The different treatment of the Audio component. - The different access of vfio-pci to the Audio component. So I will make several variations on the test scripts to try and narrow this down. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #79 from siyia (eutychio...@gmail.com) --- Will test it when i get my hands on 4.12.4 kernel -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property
On Tue, Jul 25, 2017 at 10:01:19AM +0200, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
>
> Signed-off-by: Daniel Vetter
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Jyri Sarha
> Cc: "Ville Syrjälä"
> Cc: Rongrong Zou
> Cc: Shawn Guo
> Cc: Alexey Brodkin
> Cc: Eric Engestrom
> Cc: Chris Wilson
> Cc: Rob Clark
> Cc: Archit Taneja
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Thomas Hellstrom
> Cc: Maxime Ripard
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 1 -
> drivers/gpu/drm/drm_atomic.c| 3 +-
> drivers/gpu/drm/drm_atomic_helper.c | 55
> -
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 -
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 -
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 -
> drivers/gpu/drm/i915/intel_display.c| 2 -
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 -
> drivers/gpu/drm/nouveau/nv50_display.c | 1 -
> drivers/gpu/drm/omapdrm/omap_plane.c| 1 -
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 -
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
> drivers/gpu/drm/sti/sti_cursor.c| 1 -
> drivers/gpu/drm/sti/sti_gdp.c | 1 -
> drivers/gpu/drm/sti/sti_hqvdp.c | 1 -
> drivers/gpu/drm/stm/ltdc.c | 1 -
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 1 -
> include/drm/drm_atomic.h| 3 --
> include/drm/drm_atomic_helper.h | 3 --
> 20 files changed, 1 insertion(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 600fa7bd7f52..0f0f8234fe21 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -128,7 +128,6 @@ static void malidp_plane_atomic_print_state(struct
> drm_printer *p,
> static const struct drm_plane_funcs malidp_de_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> - .set_property = drm_atomic_helper_plane_set_property,
> .destroy = malidp_de_plane_destroy,
> .reset = malidp_plane_reset,
> .atomic_duplicate_state = malidp_duplicate_plane_state,
For mali-dp changes:
Acked-by: Liviu Dudau
I'm assuming the series goes through drm-next tree.
Thanks,
Liviu
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index b5bd9b005225..9cd9e23e75c6 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -1052,7 +1052,6 @@ static void
> atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
> static struct drm_plane_funcs layer_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> - .set_property = drm_atomic_helper_plane_set_property,
> .destroy = atmel_hlcdc_plane_destroy,
> .reset = atmel_hlcdc_plane_reset,
> .atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 0fd14aff7add..395438a7a576 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -713,7 +713,7 @@ EXPORT_SYMBOL(drm_atomic_get_plane_state);
> * RETURNS:
> * Zero on success, error code on failure
> */
> -int drm_atomic_plane_set_property(struct drm_plane *plane,
> +static int drm_atomic_plane_set_property(struct drm_plane *plane,
> struct drm_plane_state *state, struct drm_property *property,
> uint64_t val)
> {
> @@ -770,7 +770,6 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>
> return 0;
> }
> -EXPORT_SYMBOL(drm_atomic_plane_set_property);
>
> /**
> * drm_atomic_plane_get_property - get property value from plane state
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 22245aa8b1aa..0482e39a7889 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2968,61 +2968,6 @@ int drm_atomic_h
Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt
On Fri, Jul 28, 2017 at 04:58:27PM +0100, Russell King - ARM Linux wrote: > On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > > initialise without an interrupt present. > > > > > > > > Signed-off-by: Russell King > > > > > > > Hi Russell, > > > > Sorry for my silence, I was on holiday this week and just came back > > today. > > > > > This isn't fully functional on ARM MPS platforms yet, but at least > > > gets us further. Without any display connected: > > > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > > [ 14.557038] tda998x 2-0070: found TDA19988 > > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd > > > on minor 0 > > > > > > With a TV connected, the driver doesn't initialise: > > > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > > [ 14.657227] tda998x 2-0070: found TDA19988 > > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw > > > configuration. > > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > > > I don't think this is correct behaviour - if we fail to set an initial > > > configuration (which will be based on the resolution of the connected > > > display) why should the driver fail to probe - it's not that there is > > > no device, it's (in this case) that there aren't the resources for the > > > chosen mode. Userspace could always try setting a different mode. > > > > > > I suspect the above failure is down to either (a) not having enough > > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > > (yet) being able to program the hdlcd pixel clock for this platform, > > > which is currently hard-coded in DT at 23.75MHz. > > > > I don't think it is the clock, if that fails then you would not see the > > r0p0 version number being printed. Due to the fact that until now HDLCD > > has run mostly on platforms that have SCP, which takes care of actual > > setup of the clocks, it is pretty lax on errors on pixel clock setup. > > Note, however, that in this case, the clock is a fixed frequency clock. > I wasn't meaning a failure to obtain the clock, I was meaning a failure > to set the appropriate rate. Yeah, we both meant the same thing. :) HDLCD is not checking that strictly that the appropriate rate was set, although looking into hdlcd_crtc_atomic_check() we do return -EINVAL if the set rate differs from what the mode wants. Maybe add a printk there to see if you hit that case? > > > Also, may I ask what MPS platform you are trying to use? I might be able > > to source one internally and try to reproduce your problems. > > I'll point you in the direction of Ian Rickards in ARM for that > information. (I'm not sure if I can mention the board publically > yet as its early days...) Thanks, I'll get in touch with Ian. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #3 from network...@rkmail.ru --- (In reply to network723 from comment #2) > It still hangs on 5c1241268ba9b240cb79ab9a30c5255b176c83c9 I've tried bisecting, and looks like the bad commit somewhere between 7257c171e9eadc05903140cffa26a253f0d0178a and 5c1241268ba9b240cb79ab9a30c5255b176c83c9 Unfortunately, I have no time to bisect it further. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #11 from Alex Deucher --- Note that the GPU reset in patch 3/2 requires access to pci config registers for the GPU which many hypervisors block, so you'd need to make sure that works for the reset to work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #10 from Robin --- Created attachment 133101 --> https://bugs.freedesktop.org/attachment.cgi?id=133101&action=edit 4.13rc2 ubuntu kern.log Inspecting the output more closely there's a subtle difference in the error produced. While the 4.10 kernel produces: > [ 160.013733] [drm:ci_dpm_enable [amdgpu]] *ERROR* ci_start_dpm failed > [ 160.014134] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block > failed -22 The 4.13rc2, drm-next-4.14-wip and drm-next-4.14-wip with patch 3 produce: > [ 134.226312] [drm:cik_sdma_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 9 > test failed (0xCAFEDEAD) > [ 134.226822] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block > failed -22 And something I noticed for the third bind error cases, the 2nd and 3rd time have much longer ring 1 tests than the first bind. > [ 69.938959] [drm] ring test on 1 succeeded in 2 usecs > ... > [ 102.040253] [drm] ring test on 1 succeeded in 677 usecs > ... > [ 134.121468] [drm] ring test on 1 succeeded in 677 usecs -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt
On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > initialise without an interrupt present. > > > > Signed-off-by: Russell King > Hi Russell, Sorry for my silence, I was on holiday this week and just came back today. > This isn't fully functional on ARM MPS platforms yet, but at least > gets us further. Without any display connected: > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > [ 14.557038] tda998x 2-0070: found TDA19988 > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 14.639335] [drm] No driver support for vblank timestamp query. > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on > minor 0 > > With a TV connected, the driver doesn't initialise: > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > [ 14.657227] tda998x 2-0070: found TDA19988 > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 14.739538] [drm] No driver support for vblank timestamp query. > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > I don't think this is correct behaviour - if we fail to set an initial > configuration (which will be based on the resolution of the connected > display) why should the driver fail to probe - it's not that there is > no device, it's (in this case) that there aren't the resources for the > chosen mode. Userspace could always try setting a different mode. > > I suspect the above failure is down to either (a) not having enough > memory available to allocate a 1920x1080 frame buffer, or (b) not > (yet) being able to program the hdlcd pixel clock for this platform, > which is currently hard-coded in DT at 23.75MHz. I don't think it is the clock, if that fails then you would not see the r0p0 version number being printed. Due to the fact that until now HDLCD has run mostly on platforms that have SCP, which takes care of actual setup of the clocks, it is pretty lax on errors on pixel clock setup. That is the reason why I have added the 'clocks' entry in debugfs, to be able to find out the actual clock setup vs what HDLCD would like to have for the current mode. If is quite likely to be a memory issue (-12 points that way too). Also, may I ask what MPS platform you are trying to use? I might be able to source one internally and try to reproduce your problems. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 73510, which changed state. Bug 73510 Summary: ocl-toys smallptgpu example fails on r600 https://bugs.freedesktop.org/show_bug.cgi?id=73510 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 73510] ocl-toys smallptgpu example fails on r600
https://bugs.freedesktop.org/show_bug.cgi?id=73510 Jan Vesely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jan Vesely --- This is an old bug. All ocl-toys examples run OK on my AMD TURKS (DRM 2.49.0 / 4.11.11-300.fc26.x86_64, LLVM 6.0.0). Please reopen if you still see the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #9 from Robin --- Created attachment 133100 --> https://bugs.freedesktop.org/attachment.cgi?id=133100&action=edit kern.log for drm-next-4.14-wip with patch 3 Same issue with patch3. I've attached the kern.log of one of the occasions where it gave the init error on the 3rd time binding amdgpu, rather than the 2nd. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #2 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #1) > It might be related to the CLEAR_STATE changes, can you checkout to > 5c1241268ba9b240cb79ab9a30c5255b176c83c9 and try to reproduce the issue? > Thanks! It still hangs on 5c1241268ba9b240cb79ab9a30c5255b176c83c9 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 Marek Olšák (mar...@gmail.com) changed: What|Removed |Added Attachment #257745|0 |1 is obsolete|| -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #78 from Marek Olšák (mar...@gmail.com) --- Created attachment 257747 --> https://bugzilla.kernel.org/attachment.cgi?id=257747&action=edit possible final fix? Please try this patch instead. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #77 from Alexander Tsoy (alexan...@tsoy.me) --- Can't test right now. BTW, why HAINAN_GB_ADDR_CONFIG_GOLDEN value is different in different headers? ./amdgpu/sid.h:#define HAINAN_GB_ADDR_CONFIG_GOLDEN0x02010001 ./amdgpu/si_enums.h:#define HAINAN_GB_ADDR_CONFIG_GOLDEN0x02011003 VERDE_GB_ADDR_CONFIG_GOLDEN and TAHITI_GB_ADDR_CONFIG_GOLDEN values are the same, for example: ./amdgpu/sid.h:#define VERDE_GB_ADDR_CONFIG_GOLDEN 0x12010002 ./amdgpu/si_enums.h:#define VERDE_GB_ADDR_CONFIG_GOLDEN 0x02010002 ./amdgpu/sid.h:#define TAHITI_GB_ADDR_CONFIG_GOLDEN0x12011003 ./amdgpu/si_enums.h:#define TAHITI_GB_ADDR_CONFIG_GOLDEN0x12011003 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/1] amdgpu: Add FX-9800P Bristol Ridge iGPU id
Signed-off-by: Jan Vesely --- data/amdgpu.ids | 1 + 1 file changed, 1 insertion(+) diff --git a/data/amdgpu.ids b/data/amdgpu.ids index 0b98c3c3..f6c65dd9 100644 --- a/data/amdgpu.ids +++ b/data/amdgpu.ids @@ -153,6 +153,7 @@ 9874, C5, AMD Radeon R6 Graphics 9874, C6, AMD Radeon R6 Graphics 9874, C7, AMD Radeon R5 Graphics +9874, C8, AMD Radeon R7 Graphics 9874, 81, AMD Radeon R6 Graphics 9874, 87, AMD Radeon R5 Graphics 9874, 85, AMD Radeon R6 Graphics -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #8 from Alex Deucher --- Created attachment 133099 --> https://bugs.freedesktop.org/attachment.cgi?id=133099&action=edit possible fix 3/2 Dos using this patch on top of the other two help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/1] drmsltest: Check expected neighbours
Fixes: 7d8c9464081634f053e16e5eac9655a12fae1dc4
Signed-off-by: Jan Vesely
---
I thought I sent this out, but couldn't find it in sent mail.
This tests the behaviour set in 3b2ee2b5bfc0d68525fee936e51297a9b6c629f1
more than 2 years ago
Jan
tests/drmsl.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/tests/drmsl.c b/tests/drmsl.c
index d0ac0efa..d1b59a86 100644
--- a/tests/drmsl.c
+++ b/tests/drmsl.c
@@ -106,7 +106,9 @@ static double do_time(int size, int iter)
return usec;
}
-static void print_neighbors(void *list, unsigned long key)
+static void print_neighbors(void *list, unsigned long key,
+unsigned long expected_prev,
+unsigned long expected_next)
{
unsigned long prev_key = 0;
unsigned long next_key = 0;
@@ -119,6 +121,16 @@ static void print_neighbors(void *list, unsigned long key)
&next_key, &next_value);
printf("Neighbors of %5lu: %d %5lu %5lu\n",
key, retval, prev_key, next_key);
+if (prev_key != expected_prev) {
+fprintf(stderr, "Unexpected neighbor: %5lu. Expected: %5lu\n",
+prev_key, expected_prev);
+ exit(1);
+}
+if (next_key != expected_next) {
+fprintf(stderr, "Unexpected neighbor: %5lu. Expected: %5lu\n",
+next_key, expected_next);
+ exit(1);
+}
}
int main(void)
@@ -138,13 +150,13 @@ int main(void)
print(list);
printf("\n==\n\n");
-print_neighbors(list, 0);
-print_neighbors(list, 50);
-print_neighbors(list, 51);
-print_neighbors(list, 123);
-print_neighbors(list, 200);
-print_neighbors(list, 213);
-print_neighbors(list, 256);
+print_neighbors(list, 0, 0, 50);
+print_neighbors(list, 50, 0, 50);
+print_neighbors(list, 51, 50, 123);
+print_neighbors(list, 123, 50, 123);
+print_neighbors(list, 200, 123, 213);
+print_neighbors(list, 213, 123, 213);
+print_neighbors(list, 256, 213, 256);
printf("\n==\n\n");
drmSLDelete(list, 50);
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 10bit output via KMS
Am 28.07.2017 um 11:55 schrieb Volker Vogelhuber: Hi, On 24 July 2017 at 14:56, Volker Vogelhuber wrote: I wonder if it is possible to have drmModeAddFB2 to handle 'X', 'R', '3', '0' at all. So is this supported in any way? Secondly, you're correct that you would need (theoretically) to extend drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in the last 10 years. This is the 'XR30' FourCC you mention, so it should already be there and working in the kernel. This question probably better fits to the drm mailing list, although the discussion started on the mesa list. I got it working now that my 10bit buffers are correctly displayed on a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0' fourcc code. Based on the Samsung's datasheet it should support 10bit signals, although the EDID does not seem to contain a vendor specific data block that would confirm that assumption. I have connected an Apollo Lake module with a display port cable to that display but I'm unsure if it's really 10bit or if there is some conversion logic somewhere in between that may downsample my 10 bit buffer to 8bit before sending it via displayport to the display. Well you could just try to display a 10bit image with a gradient going from black to white. The difference between 8bit and 10bit should be obvious even to the naked eye. Christian. So far I stumbled over some patches regarding color management in the drm part of the kernel, but couldn't figure out how one could configure what is really send to the display. It seem to mostly be used to manipulate gamma values and so on. As the only indicator what is provided to the display is the buffer format handled by drmModeAddFB2 I doubt this is enough to configure the signal. Otherwise one could argue that the link speed of the display signal would have to toggle every time I send a different buffer format, which is certainly not the case. So what portion of the kms/drm chain do I miss currently? The drmModeModeInfo pointer has a clock field, but I guess this is meant to be for the pixel clock not the clock of the serialized signal. Probably that's why I couldn't find modelines for 4k@60 especially for 10bit compared to 8bit. Thanks Volker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #76 from Marek Olšák (mar...@gmail.com) --- Created attachment 257745 --> https://bugzilla.kernel.org/attachment.cgi?id=257745&action=edit possible final fix? Can you please test this patch? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] drm/msm/adreno: Prevent unclocked access when retrieving timestamps
On Fri, Jul 28, 2017 at 04:17:08PM +0530, Archit Taneja wrote:
> msm_gpu's get_timestamp() op (called by the MSM_GET_PARAM ioctl) can
> result in register accesses. We need our power domain and clocks to
> be active for that. Make sure they are enabled here.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index f1ab2703674a..7414c6bbd582 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -48,8 +48,15 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
> uint64_t *value)
> *value = adreno_gpu->base.fast_rate;
> return 0;
> case MSM_PARAM_TIMESTAMP:
> - if (adreno_gpu->funcs->get_timestamp)
> - return adreno_gpu->funcs->get_timestamp(gpu, value);
> + if (adreno_gpu->funcs->get_timestamp) {
> + int ret;
> +
> + pm_runtime_get_sync(&gpu->pdev->dev);
> + ret = adreno_gpu->funcs->get_timestamp(gpu, value);
> + pm_runtime_put_autosuspend(&gpu->pdev->dev);
> +
> + return ret;
> + }
> return -EINVAL;
> default:
> DBG("%s: invalid param: %u", gpu->name, param);
This is clearly correct from a stability standpoint but it does raise
a few side questions.
When the system is idle it is not interesting to go to all the work of bringing
up the system to read a timestamp that will be 0 (or very close to it) and then
take the system down again. Furthermore when the system is going up and down
repeatedly between submits the counter will keep getting reset to zero and
makes it less useful over the long term.
Downstream had these problems too and has an elaborate mechanism to save the
value of the counters at power down and (on 4XX and newer) reload the
counters with the previous value when power comes back. This has the advantage
of consistent numbers with the downside of a reasonable amount of work to
maintain the database of allocated counters and taking the to save them on
power down and restore them on power up.
This patch should be obviously merged because system hangs are bad but I just
wanted to toss out more food for thought as we get more power aggressive and
more interested in performance monitoring.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal
Am Mittwoch, 26. Juli 2017, 14:19:39 CEST schrieb Mark Yao: > It's a hardware bug, all window's overlay channel reset > value is same, hardware overlay would be die. > > so we must initial difference id for each overlay channel. > > The Channel register is supported on all vop will full design. > Following is the details for this register > VOP_WIN0_CTRL2 > bit[7:4] win_rid_win0_cbr >axi read id of win0 cbr channel > bit[3:0] win_rid_win0_yrgb >axi read id of win0 yrgb channel > > Signed-off-by: Mark Yao rk3036 and rk3288 are not negatively affected by this, so on rk3036 and rk3288 Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/7] drm/rockchip: vop: add a series of vop support
Am Mittwoch, 26. Juli 2017, 14:19:30 CEST schrieb Mark Yao: > Vop Full framework now has following vops: > IP versionchipname > 3.1 rk3288 > 3.2 rk3368 > 3.4 rk3366 > 3.5 rk3399 big > 3.6 rk3399 lit > 3.7 rk3228 > 3.8 rk3328 > > The above IP version is from H/W define, some of vop support get > the IP version from VERSION_INFO register, some are not. > hardcode the IP version for each vop to identify them. > > major version: used for IP structure, Vop full framework is 3, >vop little framework is 2. > minor version: on same structure, newer design vop will bigger >then old one. > > Signed-off-by: Mark Yao on rk3036 and rk3288 Tested-by: Heiko Stuebner Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #1 from Samuel Pitoiset --- It might be related to the CLEAR_STATE changes, can you checkout to 5c1241268ba9b240cb79ab9a30c5255b176c83c9 and try to reproduce the issue? Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 Bug ID: 101961 Summary: Serious Sam Fusion hangs system completely Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: network...@rkmail.ru QA Contact: dri-devel@lists.freedesktop.org I'm running Mesa git master 3f38e64270c03c9a9eb5368c06dcfd1896fbf6d0 and my computers stops responding any input after few seconds of playing Serious Sam Fusion. The computer is unreachable over network after the crash, and no related logs are saved on disk. Git master c4652a0a5b5eef32f31baa1187ecd2612ac1009d of yesterday used to work fine. Hardware: RX 480 Kernel: 4.12.3 Distro: openSUSE 42.2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #7 from Robin --- Created attachment 133098 --> https://bugs.freedesktop.org/attachment.cgi?id=133098&action=edit kern.log for drm-next-4.14-wip Building the drm-next-4.14-wip branch including both patches does not resolve the issue and behaves similar to the previous 4.13rc2 kernel regarding ring test errors showing up. Typically 1, 9 and/or 10. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-hybrid-4.11 1375/2257] drivers/gpu/drm/radeon/radeon_kfd.c:1426:32: warning: cast to pointer from integer of different size
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-hybrid-4.11 head: 4e9a9bc851d8ecea7b6cabb485f1aa3e914a42a9 commit: f271ce43981644c2dd9832f9014b58b3196f [1375/2257] radeon_kfd.c copied config: i386-randconfig-i1-201730 (attached as .config) compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 reproduce: git checkout f271ce43981644c2dd9832f9014b58b3196f # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): drivers/gpu/drm/radeon/radeon_kfd.c: In function 'get_pdd_from_buffer_object': drivers/gpu/drm/radeon/radeon_kfd.c:219:22: error: 'struct radeon_bo' has no member named 'pdd' return mem->data2.bo->pdd; ^ drivers/gpu/drm/radeon/radeon_kfd.c: In function 'open_graphic_handle': drivers/gpu/drm/radeon/radeon_kfd.c:516:2: warning: passing argument 1 of 'drm_gem_object_lookup' from incompatible pointer type [enabled by default] gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle); ^ In file included from drivers/gpu/drm/radeon/radeon.h:77:0, from drivers/gpu/drm/radeon/radeon_kfd.c:27: include/drm/drm_gem.h:241:24: note: expected 'struct drm_file *' but argument is of type 'struct drm_device *' struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 handle); ^ drivers/gpu/drm/radeon/radeon_kfd.c:516:2: warning: passing argument 2 of 'drm_gem_object_lookup' makes integer from pointer without a cast [enabled by default] gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle); ^ In file included from drivers/gpu/drm/radeon/radeon.h:77:0, from drivers/gpu/drm/radeon/radeon_kfd.c:27: include/drm/drm_gem.h:241:24: note: expected 'u32' but argument is of type 'void *' struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 handle); ^ drivers/gpu/drm/radeon/radeon_kfd.c:516:2: error: too many arguments to function 'drm_gem_object_lookup' gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle); ^ In file included from drivers/gpu/drm/radeon/radeon.h:77:0, from drivers/gpu/drm/radeon/radeon_kfd.c:27: include/drm/drm_gem.h:241:24: note: declared here struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 handle); ^ drivers/gpu/drm/radeon/radeon_kfd.c: In function 'map_bo_to_gpuvm': drivers/gpu/drm/radeon/radeon_kfd.c:1271:3: error: too many arguments to function 'ttm_bo_wait' ret = ttm_bo_wait(&bo->tbo, true, false, false); ^ In file included from drivers/gpu/drm/radeon/radeon.h:71:0, from drivers/gpu/drm/radeon/radeon_kfd.c:27: include/drm/ttm/ttm_bo_api.h:292:12: note: declared here extern int ttm_bo_wait(struct ttm_buffer_object *bo, ^ drivers/gpu/drm/radeon/radeon_kfd.c: In function 'write_config_static_mem': drivers/gpu/drm/radeon/radeon_kfd.c:1368:26: error: 'SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT' undeclared (first use in this function) reg = swizzle_enable << SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT | ^ drivers/gpu/drm/radeon/radeon_kfd.c:1368:26: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/radeon/radeon_kfd.c:1369:19: error: 'SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT' undeclared (first use in this function) element_size << SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT | ^ drivers/gpu/drm/radeon/radeon_kfd.c:1370:19: error: 'SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT' undeclared (first use in this function) index_stride << SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT | ^ drivers/gpu/drm/radeon/radeon_kfd.c:1371:19: error: 'SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT' undeclared (first use in this function) index_stride << SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT; ^ In file included from drivers/gpu/drm/radeon/radeon_kfd.c:27:0: drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_scratch': drivers/gpu/drm/radeon/radeon_kfd.c:1382:9: error: 'SH_HIDDEN_PRIVATE_BASE_VMID' undeclared (first use in this function) WREG32(SH_HIDDEN_PRIVATE_BASE_VMID, va); ^ drivers/gpu/drm/radeon/radeon.h:2545:44: note: in definition of macro 'WREG32' #define WREG32(reg, v) r100_mm_wreg(rdev, (reg), (v), false) ^ drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_gpu': drivers/gpu/drm/radeon/radeon_kfd.c:1421:4: error: 'struct radeon_bo' has no member named 'pdd' bo->pdd = pdd; ^ In file included from include/linux/kernel.h:13:0, from include/linux/list.h:8, fro
[radeon-alex:amd-mainline-hybrid-4.11 1373/2257] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:352:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 're
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-hybrid-4.11
head: 4e9a9bc851d8ecea7b6cabb485f1aa3e914a42a9
commit: a2a89723a7d85d57bad83a0baa839d18f0db0805 [1373/2257] port in all files
config: i386-randconfig-i1-201730 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout a2a89723a7d85d57bad83a0baa839d18f0db0805
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function
'amdgdu_amdkfd_restore_mem_worker':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:193:22: error: 'struct amdgpu_bo'
has no member named 'adev'
adev = mem->data2.bo->adev;
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function 'get_local_mem_info':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:342:2: warning: left shift count
>= width of type [enabled by default]
address_mask = ~((1UL << 40) - 1);
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:352:3: warning: format '%llx'
>> expects argument of type 'long long unsigned int', but argument 2 has type
>> 'resource_size_t' [-Wformat=]
pr_err("amdgpu: vram aperture is out of 40bit address base: 0x%llx limit
0x%llx\n",
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:352:3: warning: format '%llx'
expects argument of type 'long long unsigned int', but argument 3 has type
'resource_size_t' [-Wformat=]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:2: warning: format '%llx'
expects argument of type 'long long unsigned int', but argument 2 has type
'resource_size_t' [-Wformat=]
pr_debug("amdgpu: address base: 0x%llx limit 0x%llx public 0x%llx private
0x%llx\n",
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:356:2: warning: format '%llx'
expects argument of type 'long long unsigned int', but argument 3 has type
'resource_size_t' [-Wformat=]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:361:6: error: 'amdgpu_powerplay'
undeclared (first use in this function)
if (amdgpu_powerplay || rdev->pm.funcs->get_mclk)
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:361:6: note: each undeclared
identifier is reported only once for each function it appears in
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function
'get_max_engine_clock_in_mhz':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:379:6: error: 'amdgpu_powerplay'
undeclared (first use in this function)
if (amdgpu_powerplay)
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function 'get_cu_info':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:402:33: error: 'struct
amdgpu_cu_info' has no member named 'simd_per_cu'
cu_info->simd_per_cu = acu_info.simd_per_cu;
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:403:40: error: 'struct
amdgpu_cu_info' has no member named 'max_waves_per_simd'
cu_info->max_waves_per_simd = acu_info.max_waves_per_simd;
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:405:46: error: 'struct
amdgpu_cu_info' has no member named 'max_scratch_slots_per_cu'
cu_info->max_scratch_slots_per_cu = acu_info.max_scratch_slots_per_cu;
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:406:30: error: 'struct
amdgpu_cu_info' has no member named 'lds_size'
cu_info->lds_size = acu_info.lds_size;
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function
'amdgpu_amdkfd_get_dmabuf_info':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:432:23: error:
'drm_gem_prime_dmabuf_ops' undeclared (first use in this function)
if (dma_buf->ops != &drm_gem_prime_dmabuf_ops)
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:443:10: error: 'struct amdgpu_bo'
has no member named 'initial_domain'
if (!(bo->initial_domain & (AMDGPU_GEM_DOMAIN_VRAM |
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:459:15: error: 'struct amdgpu_bo'
has no member named 'initial_domain'
*flags = (bo->initial_domain & AMDGPU_GEM_DOMAIN_VRAM) ?
^
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c: In function
'get_max_engine_clock_in_mhz':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:383:1: warning: control reaches
end of non-void function [-Wreturn-type]
}
^
vim +352 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
183
184 static void amdgdu_amdkfd_restore_mem_worker(struct work_struct *work)
185 {
186 struct delayed_work *dwork = to_delayed_work(work);
187 struct kgd_mem *mem = container_of(dwork, struct kgd_mem,
data2.work);
188 struct amdgpu_device *adev;
189 struct mm_struct *mm;
190
191 mutex_lock(&mem->data2.lock);
192
> 193 adev = mem->data2.bo->adev;
194 mm = mem->data2.mm;
195
196 /* Restoration may have been
[Bug 101954] WARNING: suspicious RCU usage in amdgpu_bo_list_get
https://bugs.freedesktop.org/show_bug.cgi?id=101954 Yanko Kaneti changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Yanko Kaneti --- Hadn't noticed this was already brought up and fixed in a branch. Sorry fo the noise. With brief local testing it looks fixed by b7ae412c6f7050b917d8b0bf2dadb212d740d8a5 which is already in mainline -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] drm/msm/mdp5: Write to SMP registers even if allocations don't change
Requests for assigning/freeing SMP blocks by planes are collected during
the atomic check phase, and represented by mdp5_smp_state's 'assigned'
and 'released' members.
Once the atomic state is committed, these members are reset to 0,
indicating that the existing configuration satisfies all the planes.
Future atomic commits will copy the old mdp5_smp_state, and the 'assigned'
and 'released' members would be updated only if there was a change in
the plane configurations.
When we disable and re-enable display, we lose the values we wrote to the
SMP registers, but the code doesn't program the registers because there
isn't any change in mdp5_smp_state.
Fix this by writing to the registers irrespective of whether there was
a change in SMP state or not. We do this by keeping a cache of the
register values, and write them every time we commit a state.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 59 -
1 file changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 58f712d37e7f..ae4983d9d0a5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -28,6 +28,13 @@ struct mdp5_smp {
int blk_cnt;
int blk_size;
+
+ /* register cache */
+ u32 alloc_w[22];
+ u32 alloc_r[22];
+ u32 pipe_reqprio_fifo_wm0[SSPP_MAX];
+ u32 pipe_reqprio_fifo_wm1[SSPP_MAX];
+ u32 pipe_reqprio_fifo_wm2[SSPP_MAX];
};
static inline
@@ -98,16 +105,15 @@ static int smp_request_block(struct mdp5_smp *smp,
static void set_fifo_thresholds(struct mdp5_smp *smp,
enum mdp5_pipe pipe, int nblks)
{
- struct mdp5_kms *mdp5_kms = get_kms(smp);
u32 smp_entries_per_blk = smp->blk_size / (128 / BITS_PER_BYTE);
u32 val;
/* 1/4 of SMP pool that is being fetched */
val = (nblks * smp_entries_per_blk) / 4;
- mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_0(pipe), val * 1);
- mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_1(pipe), val * 2);
- mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_2(pipe), val * 3);
+ smp->pipe_reqprio_fifo_wm0[pipe] = val * 1;
+ smp->pipe_reqprio_fifo_wm1[pipe] = val * 2;
+ smp->pipe_reqprio_fifo_wm2[pipe] = val * 3;
}
/*
@@ -222,7 +228,6 @@ void mdp5_smp_release(struct mdp5_smp *smp, struct
mdp5_smp_state *state,
static unsigned update_smp_state(struct mdp5_smp *smp,
u32 cid, mdp5_smp_state_t *assigned)
{
- struct mdp5_kms *mdp5_kms = get_kms(smp);
int cnt = smp->blk_cnt;
unsigned nblks = 0;
u32 blk, val;
@@ -231,7 +236,7 @@ static unsigned update_smp_state(struct mdp5_smp *smp,
int idx = blk / 3;
int fld = blk % 3;
- val = mdp5_read(mdp5_kms, REG_MDP5_SMP_ALLOC_W_REG(idx));
+ val = smp->alloc_w[idx];
switch (fld) {
case 0:
@@ -248,8 +253,8 @@ static unsigned update_smp_state(struct mdp5_smp *smp,
break;
}
- mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_W_REG(idx), val);
- mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_R_REG(idx), val);
+ smp->alloc_w[idx] = val;
+ smp->alloc_r[idx] = val;
nblks++;
}
@@ -257,6 +262,39 @@ static unsigned update_smp_state(struct mdp5_smp *smp,
return nblks;
}
+static void write_smp_alloc_regs(struct mdp5_smp *smp)
+{
+ struct mdp5_kms *mdp5_kms = get_kms(smp);
+ int i, num_regs;
+
+ num_regs = smp->blk_cnt / 3 + 1;
+
+ for (i = 0; i < num_regs; i++) {
+ mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_W_REG(i),
+ smp->alloc_w[i]);
+ mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_R_REG(i),
+ smp->alloc_r[i]);
+ }
+}
+
+static void write_smp_fifo_regs(struct mdp5_smp *smp)
+{
+ struct mdp5_kms *mdp5_kms = get_kms(smp);
+ int i;
+
+ for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
+ struct mdp5_hw_pipe *hwpipe = mdp5_kms->hwpipes[i];
+ enum mdp5_pipe pipe = hwpipe->pipe;
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_0(pipe),
+ smp->pipe_reqprio_fifo_wm0[pipe]);
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_1(pipe),
+ smp->pipe_reqprio_fifo_wm1[pipe]);
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_2(pipe),
+ smp->pipe_reqprio_fifo_wm2[pipe]);
+ }
+}
+
void mdp5_smp_prepare_commit(struct mdp5_smp *smp, struct mdp5_smp_state
*state)
{
enum mdp5_pipe pipe;
@@ -277,6 +315,9 @@ void mdp5_smp_prepare_commit(struct mdp5_smp *smp, struct
mdp5_smp_state *state)
set_fifo_thresholds(smp, pipe,
[PATCH 09/10] drm/msm/mdp5: Set up runtime PM for MDSS
MDSS represents the top level wrapper that contains MDP5, DSI, HDMI and
other sub-blocks. W.r.t device heirarchy, it's the parent of all these
devices. The power domain of this device is actually tied to the GDSC
hw. When any sub-device enables its PD, MDSS's PD is also enabled.
The suspend/resume ops enable the top level clocks that end at the MDSS
boundary. For now, we're letting them all be optional, since the child
devices anyway hold a ref to these clocks.
Until now, we'd called a runtime_get() during probe, which ensured that
the GDSC was always on. Now that we've set up runtime PM for the children
devices, we can get rid of this hack.
Note: that the MDSS device is the platform_device in msm_drv.c. The
msm_runtime_suspend/resume ops call the funcs that enable/disable
the top level MDSS clocks. This is different from MDP4, where the
platform device created in msm_drv.c represents MDP4 itself. It would
have been nicer to hide these differences by adding new kms funcs, but
runtime PM needs to be enabled before kms is set up (i.e, msm_kms_init
is called).
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c | 63
drivers/gpu/drm/msm/msm_drv.c| 29 +++
drivers/gpu/drm/msm/msm_kms.h| 2 +
3 files changed, 86 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
index 9c34d7824988..f2a0db7a8a03 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
@@ -31,6 +31,10 @@ struct msm_mdss {
struct regulator *vdd;
+ struct clk *ahb_clk;
+ struct clk *axi_clk;
+ struct clk *vsync_clk;
+
struct {
volatile unsigned long enabled_mask;
struct irq_domain *domain;
@@ -140,6 +144,51 @@ static int mdss_irq_domain_init(struct msm_mdss *mdss)
return 0;
}
+int msm_mdss_enable(struct msm_mdss *mdss)
+{
+ DBG("");
+
+ clk_prepare_enable(mdss->ahb_clk);
+ if (mdss->axi_clk)
+ clk_prepare_enable(mdss->axi_clk);
+ if (mdss->vsync_clk)
+ clk_prepare_enable(mdss->vsync_clk);
+
+ return 0;
+}
+
+int msm_mdss_disable(struct msm_mdss *mdss)
+{
+ DBG("");
+
+ if (mdss->vsync_clk)
+ clk_disable_unprepare(mdss->vsync_clk);
+ if (mdss->axi_clk)
+ clk_disable_unprepare(mdss->axi_clk);
+ clk_disable_unprepare(mdss->ahb_clk);
+
+ return 0;
+}
+
+static int msm_mdss_get_clocks(struct msm_mdss *mdss)
+{
+ struct platform_device *pdev = to_platform_device(mdss->dev->dev);
+
+ mdss->ahb_clk = msm_clk_get(pdev, "iface");
+ if (IS_ERR(mdss->ahb_clk))
+ mdss->ahb_clk = NULL;
+
+ mdss->axi_clk = msm_clk_get(pdev, "bus");
+ if (IS_ERR(mdss->axi_clk))
+ mdss->axi_clk = NULL;
+
+ mdss->vsync_clk = msm_clk_get(pdev, "vsync");
+ if (IS_ERR(mdss->vsync_clk))
+ mdss->vsync_clk = NULL;
+
+ return 0;
+}
+
void msm_mdss_destroy(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -153,8 +202,6 @@ void msm_mdss_destroy(struct drm_device *dev)
regulator_disable(mdss->vdd);
- pm_runtime_put_sync(dev->dev);
-
pm_runtime_disable(dev->dev);
}
@@ -190,6 +237,12 @@ int msm_mdss_init(struct drm_device *dev)
goto fail;
}
+ ret = msm_mdss_get_clocks(mdss);
+ if (ret) {
+ dev_err(dev->dev, "failed to get clocks: %d\n", ret);
+ goto fail;
+ }
+
/* Regulator to enable GDSCs in downstream kernels */
mdss->vdd = devm_regulator_get(dev->dev, "vdd");
if (IS_ERR(mdss->vdd)) {
@@ -221,12 +274,6 @@ int msm_mdss_init(struct drm_device *dev)
pm_runtime_enable(dev->dev);
- /*
-* TODO: This is needed as the MDSS GDSC is only tied to MDSS's power
-* domain. Remove this once runtime PM is adapted for all the devices.
-*/
- pm_runtime_get_sync(dev->dev);
-
return 0;
fail_irq:
regulator_disable(mdss->vdd);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f49f6ac5585c..a19c393f7e45 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -879,8 +879,37 @@ static int msm_pm_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM
+static int msm_runtime_suspend(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
+
+ DBG("");
+
+ if (priv->mdss)
+ return msm_mdss_disable(priv->mdss);
+
+ return 0;
+}
+
+static int msm_runtime_resume(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
+
+ DBG("");
+
+ if (priv
[PATCH 07/10] drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs
We shouldn't use use mode_set/mode_set_nofb helpers when we use runtime
PM. The registers configured in these funcs lose their state when we
eventually enable the display pipeline.
Do not implement these vfuncs in the helpers, and call them in the
crtc_enable/encoder_enable paths instead.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 4 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 5 -
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index fb78425db52c..0de6e3436ac8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -443,6 +443,9 @@ static void mdp5_crtc_enable(struct drm_crtc *crtc)
return;
pm_runtime_get_sync(dev);
+
+ mdp5_crtc_mode_set_nofb(crtc);
+
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->err);
if (mdp5_cstate->cmd_mode)
@@ -951,7 +954,6 @@ static const struct drm_crtc_funcs
mdp5_crtc_no_lm_cursor_funcs = {
};
static const struct drm_crtc_helper_funcs mdp5_crtc_helper_funcs = {
- .mode_set_nofb = mdp5_crtc_mode_set_nofb,
.disable = mdp5_crtc_disable,
.enable = mdp5_crtc_enable,
.atomic_check = mdp5_crtc_atomic_check,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 0ca9e4033bb6..5b851380d3f2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -297,6 +297,10 @@ static void mdp5_encoder_enable(struct drm_encoder
*encoder)
{
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_interface *intf = mdp5_encoder->intf;
+ /* this isn't right I think */
+ struct drm_crtc_state *cstate = encoder->crtc->state;
+
+ mdp5_encoder_mode_set(encoder, &cstate->mode, &cstate->adjusted_mode);
if (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)
mdp5_cmd_encoder_enable(encoder);
@@ -320,7 +324,6 @@ static int mdp5_encoder_atomic_check(struct drm_encoder
*encoder,
}
static const struct drm_encoder_helper_funcs mdp5_encoder_helper_funcs = {
- .mode_set = mdp5_encoder_mode_set,
.disable = mdp5_encoder_disable,
.enable = mdp5_encoder_enable,
.atomic_check = mdp5_encoder_atomic_check,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] drm/msm/adreno: Prevent unclocked access when retrieving timestamps
msm_gpu's get_timestamp() op (called by the MSM_GET_PARAM ioctl) can
result in register accesses. We need our power domain and clocks to
be active for that. Make sure they are enabled here.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f1ab2703674a..7414c6bbd582 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -48,8 +48,15 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
*value = adreno_gpu->base.fast_rate;
return 0;
case MSM_PARAM_TIMESTAMP:
- if (adreno_gpu->funcs->get_timestamp)
- return adreno_gpu->funcs->get_timestamp(gpu, value);
+ if (adreno_gpu->funcs->get_timestamp) {
+ int ret;
+
+ pm_runtime_get_sync(&gpu->pdev->dev);
+ ret = adreno_gpu->funcs->get_timestamp(gpu, value);
+ pm_runtime_put_autosuspend(&gpu->pdev->dev);
+
+ return ret;
+ }
return -EINVAL;
default:
DBG("%s: invalid param: %u", gpu->name, param);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/msm/dsi: Implement RPM suspend/resume callbacks
The bus clocks are always enabled/disabled along with the power
domain, so move it to the runtime suspend/resume ops. This cleans
up the clock code a bit. Get rid of the clk_mutex mutex since it
isn't needed.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.c | 5 +++
drivers/gpu/drm/msm/dsi/dsi.h | 2 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 83 +++---
3 files changed, 49 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 311c1c1e7d6c..98742d7af6dc 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -161,12 +161,17 @@ static const struct of_device_id dt_match[] = {
{}
};
+static const struct dev_pm_ops dsi_pm_ops = {
+ SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume,
NULL)
+};
+
static struct platform_driver dsi_driver = {
.probe = dsi_dev_probe,
.remove = dsi_dev_remove,
.driver = {
.name = "msm_dsi",
.of_match_table = dt_match,
+ .pm = &dsi_pm_ops,
},
};
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 9e6017387efb..2302046197a8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -179,6 +179,8 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host);
int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
int msm_dsi_host_init(struct msm_dsi *msm_dsi);
+int msm_dsi_runtime_suspend(struct device *dev);
+int msm_dsi_runtime_resume(struct device *dev);
/* dsi phy */
struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index da0913a33ca0..dbb31a014419 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -135,7 +135,6 @@ struct msm_dsi_host {
struct completion video_comp;
struct mutex dev_mutex;
struct mutex cmd_mutex;
- struct mutex clk_mutex;
spinlock_t intr_lock; /* Protect interrupt ctrl register */
u32 err_work_state;
@@ -458,6 +457,34 @@ static void dsi_bus_clk_disable(struct msm_dsi_host
*msm_host)
clk_disable_unprepare(msm_host->bus_clks[i]);
}
+int msm_dsi_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+
+ if (!msm_host->cfg_hnd)
+ return 0;
+
+ dsi_bus_clk_disable(msm_host);
+
+ return 0;
+}
+
+int msm_dsi_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+
+ if (!msm_host->cfg_hnd)
+ return 0;
+
+ return dsi_bus_clk_enable(msm_host);
+}
+
static int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
{
int ret;
@@ -599,35 +626,6 @@ static void dsi_link_clk_disable(struct msm_dsi_host
*msm_host)
}
}
-static int dsi_clk_ctrl(struct msm_dsi_host *msm_host, bool enable)
-{
- int ret = 0;
-
- mutex_lock(&msm_host->clk_mutex);
- if (enable) {
- ret = dsi_bus_clk_enable(msm_host);
- if (ret) {
- pr_err("%s: Can not enable bus clk, %d\n",
- __func__, ret);
- goto unlock_ret;
- }
- ret = dsi_link_clk_enable(msm_host);
- if (ret) {
- pr_err("%s: Can not enable link clk, %d\n",
- __func__, ret);
- dsi_bus_clk_disable(msm_host);
- goto unlock_ret;
- }
- } else {
- dsi_link_clk_disable(msm_host);
- dsi_bus_clk_disable(msm_host);
- }
-
-unlock_ret:
- mutex_unlock(&msm_host->clk_mutex);
- return ret;
-}
-
static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
{
struct drm_display_mode *mode = msm_host->mode;
@@ -1702,6 +1700,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
}
msm_host->pdev = pdev;
+ msm_dsi->host = &msm_host->base;
ret = dsi_host_parse_dt(msm_host);
if (ret) {
@@ -1758,7 +1757,6 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
init_completion(&msm_host->video_comp);
mutex_init(&msm_host->dev_mutex);
mutex_init(&msm_host->cmd_mutex);
- mutex_init(&msm_host->clk_mutex);
spin_lock_init(&msm_host->intr_lock);
/* setup workqueue */
@@ -1766,7 +1764,6 @@ int msm_dsi_host_init(struct msm_dsi
[PATCH 00/10] drm/msm: Runtime PM for MDP5 based devices
This series sets up runtime PM for MDP5 based SoCs. We have a top level MDSS device, which parents devices like MDP5, DSI, HDMI etc. The parent child relation between them establishes a similar relationship for their power domains too. In the HW (and the DT bindings), only MDSS has control over the power domain (i.e, the MDSS GDSC). In software, we do the same by assigning the GDSC to MDSS, and the children end up voting for the GDSC by calling the pm_runtime_get/put() API. For this to work, we need to convert all the child drivers to DT. The patchset converts MDP5, DSI and HDMI to use runtime PM. The first 2 patches and the last patch are minor fixes not directly related to runtime PM. Tested on DB410c and DB820c. Archit Taneja (10): drm/msm/mdp5: Fix typo in encoder_enable path drm/msm/mdp5: Drop clock names with "_clk" suffix drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks drm/msm/hdmi: Set up runtime PM for HDMI drm/msm/dsi: Set up runtime PM for DSI drm/msm/dsi: Implement RPM suspend/resume callbacks drm/msm/mdp5: Don't use mode_set helper funcs for encoders and CRTCs drm/msm/mdp5: Write to SMP registers even if allocations don't change drm/msm/mdp5: Set up runtime PM for MDSS drm/msm/adreno: Prevent unclocked access when retrieving timestamps drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 ++- drivers/gpu/drm/msm/dsi/dsi.c | 5 ++ drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi_host.c | 94 ++--- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 2 + drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4 ++ drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 63 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 7 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 25 --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 14 ++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 27 --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 63 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 3 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c| 63 ++--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 59 +--- drivers/gpu/drm/msm/msm_drv.c | 29 drivers/gpu/drm/msm/msm_kms.h | 2 + 18 files changed, 350 insertions(+), 125 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/msm/hdmi: Set up runtime PM for HDMI
Enable rudimentary runtime PM in the HDMI driver. We can't really do
agressive PM toggling at the moment because we need to leave the hpd
clocks enabled all the time. There isn't much benefit of creating
suspend/resume ops to toggle clocks either.
We just make sure that we configure the power domain in the HDMI bridge's
enable/disable paths, and the HDMI connector's detect() op.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 4 ++
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 63 +--
3 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index a968cad509c2..17e069a133a4 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -239,6 +239,8 @@ static struct hdmi *msm_hdmi_init(struct platform_device
*pdev)
hdmi->pwr_clks[i] = clk;
}
+ pm_runtime_enable(&pdev->dev);
+
hdmi->workq = alloc_ordered_workqueue("msm_hdmi", 0);
hdmi->i2c = msm_hdmi_i2c_init(hdmi);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index ae40e7179d4f..e9b5e886e747 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -35,6 +35,8 @@ static void msm_hdmi_power_on(struct drm_bridge *bridge)
const struct hdmi_platform_config *config = hdmi->config;
int i, ret;
+ pm_runtime_get_sync(&hdmi->pdev->dev);
+
for (i = 0; i < config->pwr_reg_cnt; i++) {
ret = regulator_enable(hdmi->pwr_regs[i]);
if (ret) {
@@ -84,6 +86,8 @@ static void power_off(struct drm_bridge *bridge)
config->pwr_reg_names[i], ret);
}
}
+
+ pm_runtime_put_autosuspend(&hdmi->pdev->dev);
}
#define AVI_IFRAME_LINE_NUMBER 1
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 2a23b92f585f..5a57a81665b9 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -137,6 +137,36 @@ static int gpio_config(struct hdmi *hdmi, bool on)
return ret;
}
+static void enable_hpd_clocks(struct hdmi *hdmi, bool enable)
+{
+ const struct hdmi_platform_config *config = hdmi->config;
+ struct device *dev = &hdmi->pdev->dev;
+ int i, ret;
+
+ if (enable) {
+ for (i = 0; i < config->hpd_clk_cnt; i++) {
+ if (config->hpd_freq && config->hpd_freq[i]) {
+ ret = clk_set_rate(hdmi->hpd_clks[i],
+ config->hpd_freq[i]);
+ if (ret)
+ dev_warn(dev,
+"failed to set clk %s (%d)\n",
+config->hpd_clk_names[i], ret);
+ }
+
+ ret = clk_prepare_enable(hdmi->hpd_clks[i]);
+ if (ret) {
+ dev_err(dev,
+ "failed to enable hpd clk: %s (%d)\n",
+ config->hpd_clk_names[i], ret);
+ }
+ }
+ } else {
+ for (i = config->hpd_clk_cnt - 1; i >= 0; i--)
+ clk_disable_unprepare(hdmi->hpd_clks[i]);
+ }
+}
+
static int hpd_enable(struct hdmi_connector *hdmi_connector)
{
struct hdmi *hdmi = hdmi_connector->hdmi;
@@ -167,22 +197,8 @@ static int hpd_enable(struct hdmi_connector
*hdmi_connector)
goto fail;
}
- for (i = 0; i < config->hpd_clk_cnt; i++) {
- if (config->hpd_freq && config->hpd_freq[i]) {
- ret = clk_set_rate(hdmi->hpd_clks[i],
- config->hpd_freq[i]);
- if (ret)
- dev_warn(dev, "failed to set clk %s (%d)\n",
- config->hpd_clk_names[i], ret);
- }
-
- ret = clk_prepare_enable(hdmi->hpd_clks[i]);
- if (ret) {
- dev_err(dev, "failed to enable hpd clk: %s (%d)\n",
- config->hpd_clk_names[i], ret);
- goto fail;
- }
- }
+ pm_runtime_get_sync(dev);
+ enable_hpd_clocks(hdmi, true);
msm_hdmi_set_mode(hdmi, false);
msm_hdmi_phy_reset(hdmi);
@@ -232,8 +248,8 @@ static void hdp_disable(struct hdmi_connector
*hdmi_connector)
msm_hdmi_set_mode(hdmi, false);
- for (i = 0; i < config->hpd_clk_cnt; i++)
- clk_disable_unprepare(hdmi->hpd_clks[i]);
+ enable_hpd_clocks(hdmi, false);
[PATCH 05/10] drm/msm/dsi: Set up runtime PM for DSI
Call the pm_runtime_get/put API where we need the clocks enabled.
The main entry/exit points are 1) enabling/disabling the DSI bridge
and 2) Sending commands from the DSI host to the device.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c| 11 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c7b612c3d771..da0913a33ca0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -221,6 +221,8 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
goto put_gdsc;
}
+ pm_runtime_get_sync(dev);
+
ret = regulator_enable(gdsc_reg);
if (ret) {
pr_err("%s: unable to enable gdsc\n", __func__);
@@ -247,6 +249,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config(
clk_disable_unprepare(ahb_clk);
disable_gdsc:
regulator_disable(gdsc_reg);
+ pm_runtime_put_autosuspend(dev);
put_clk:
clk_put(ahb_clk);
put_gdsc:
@@ -1713,6 +1716,8 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
+ pm_runtime_enable(&pdev->dev);
+
msm_host->cfg_hnd = dsi_get_config(msm_host);
if (!msm_host->cfg_hnd) {
ret = -EINVAL;
@@ -1786,6 +1791,8 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
mutex_destroy(&msm_host->clk_mutex);
mutex_destroy(&msm_host->cmd_mutex);
mutex_destroy(&msm_host->dev_mutex);
+
+ pm_runtime_disable(&msm_host->pdev->dev);
}
int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
@@ -1881,6 +1888,7 @@ int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
* mdss interrupt is generated in mdp core clock domain
* mdp clock need to be enabled to receive dsi interrupt
*/
+ pm_runtime_get_sync(&msm_host->pdev->dev);
dsi_clk_ctrl(msm_host, 1);
/* TODO: vote for bus bandwidth */
@@ -1912,6 +1920,7 @@ void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
/* TODO: unvote for bus bandwidth */
dsi_clk_ctrl(msm_host, 0);
+ pm_runtime_put_autosuspend(&msm_host->pdev->dev);
}
int msm_dsi_host_cmd_tx(struct mipi_dsi_host *host,
@@ -2217,6 +2226,7 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
goto unlock_ret;
}
+ pm_runtime_get_sync(&msm_host->pdev->dev);
ret = dsi_clk_ctrl(msm_host, 1);
if (ret) {
pr_err("%s: failed to enable clocks. ret=%d\n", __func__, ret);
@@ -2269,6 +2279,7 @@ int msm_dsi_host_power_off(struct mipi_dsi_host *host)
pinctrl_pm_select_sleep_state(&msm_host->pdev->dev);
dsi_clk_ctrl(msm_host, 0);
+ pm_runtime_put_autosuspend(&msm_host->pdev->dev);
dsi_host_regulator_disable(msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 0c2eb9c9a1fc..7c9bf91bc22b 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -373,7 +373,7 @@ static int dsi_phy_enable_resource(struct msm_dsi_phy *phy)
static void dsi_phy_disable_resource(struct msm_dsi_phy *phy)
{
clk_disable_unprepare(phy->ahb_clk);
- pm_runtime_put_sync(&phy->pdev->dev);
+ pm_runtime_put_autosuspend(&phy->pdev->dev);
}
static const struct of_device_id dsi_phy_dt_match[] = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/10] drm/msm/mdp5: Fix typo in encoder_enable path
The mdp5_cmd_encoder_disable is accidentally called in the encoder enable path. We've not seen any problems since we haven't tested with command mode panels in a while. Fix the copy-paste error. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c index 97f3294fbfc6..70bef51245af 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c @@ -299,7 +299,7 @@ static void mdp5_encoder_enable(struct drm_encoder *encoder) struct mdp5_interface *intf = mdp5_encoder->intf; if (intf->mode == MDP5_INTF_DSI_MODE_COMMAND) - mdp5_cmd_encoder_disable(encoder); + mdp5_cmd_encoder_enable(encoder); else mdp5_vid_encoder_enable(encoder); } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] drm/msm/mdp5: Use runtime PM get/put API instead of toggling clocks
mdp5_enable/disable calls are scattered all around in the MDP5 code.
Use the pm_runtime_get/put calls here instead, and populate the
runtime PM suspend/resume ops to manage the clocks.
About the overall design: MDP5 is a child of the top level MDSS
device. MDSS is also the parent to DSI, HDMI and other interfaces. When
we enable MDP5's power domain, we end up enabling MDSS's PD too. It is
only MDSS's PD that actually controlls the GDSC HW. Therefore, calling
runtime_get/put on the MDP5 device is like just requesting a vote to
enable/disable the GDSC.
Functionally, replacing the clock enable/disable calls with the RPM API
can result in the power domain (GDSC) state being toggled if no other
child isn't powered on. This can result in the register context being lost.
We make sure (in future commits) that code paths don't end up configuring
registers and then later lose state, resulting in a bad HW state.
For now, we've replaced each mdp5_enable/disable with runtime_get/put API.
We could optimize things later by removing runtime_get/put calls which
don't really need to be there. This could prevent unnecessary toggling of
the power domain and clocks.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 7 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 21 +++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 7 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 27 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 49 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 3 --
6 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
index aa7402e03f67..60790df91bfa 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -192,6 +192,7 @@ int mdp5_cmd_encoder_set_split_display(struct drm_encoder
*encoder,
{
struct mdp5_encoder *mdp5_cmd_enc = to_mdp5_encoder(encoder);
struct mdp5_kms *mdp5_kms;
+ struct device *dev;
int intf_num;
u32 data = 0;
@@ -214,14 +215,16 @@ int mdp5_cmd_encoder_set_split_display(struct drm_encoder
*encoder,
/* Smart Panel, Sync mode */
data |= MDP5_SPLIT_DPL_UPPER_SMART_PANEL;
+ dev = &mdp5_kms->pdev->dev;
+
/* Make sure clocks are on when connectors calling this function. */
- mdp5_enable(mdp5_kms);
+ pm_runtime_get_sync(dev);
mdp5_write(mdp5_kms, REG_MDP5_SPLIT_DPL_UPPER, data);
mdp5_write(mdp5_kms, REG_MDP5_SPLIT_DPL_LOWER,
MDP5_SPLIT_DPL_LOWER_SMART_PANEL);
mdp5_write(mdp5_kms, REG_MDP5_SPLIT_DPL_EN, 1);
- mdp5_disable(mdp5_kms);
+ pm_runtime_put_autosuspend(dev);
return 0;
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 9d01656d853e..fb78425db52c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -414,6 +414,7 @@ static void mdp5_crtc_disable(struct drm_crtc *crtc)
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
+ struct device *dev = &mdp5_kms->pdev->dev;
DBG("%s", crtc->name);
@@ -424,7 +425,7 @@ static void mdp5_crtc_disable(struct drm_crtc *crtc)
mdp_irq_unregister(&mdp5_kms->base, &mdp5_crtc->pp_done);
mdp_irq_unregister(&mdp5_kms->base, &mdp5_crtc->err);
- mdp5_disable(mdp5_kms);
+ pm_runtime_put_autosuspend(dev);
mdp5_crtc->enabled = false;
}
@@ -434,13 +435,14 @@ static void mdp5_crtc_enable(struct drm_crtc *crtc)
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
+ struct device *dev = &mdp5_kms->pdev->dev;
DBG("%s", crtc->name);
if (WARN_ON(mdp5_crtc->enabled))
return;
- mdp5_enable(mdp5_kms);
+ pm_runtime_get_sync(dev);
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->err);
if (mdp5_cstate->cmd_mode)
@@ -725,6 +727,7 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
struct mdp5_pipeline *pipeline = &mdp5_cstate->pipeline;
struct drm_device *dev = crtc->dev;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
+ struct platform_device *pdev = mdp5_kms->pdev;
struct msm_kms *kms = &mdp5_kms->base.base;
struct drm_gem_object *cursor_bo, *old_bo = NULL;
uint32_t blendcfg, stride;
@@ -753,7 +756,7 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
if (!handle) {
DBG("Cursor off");
cursor_enable = false;
- mdp5_enable(mdp5_kms);
+
[PATCH 02/10] drm/msm/mdp5: Drop clock names with "_clk" suffix
We have upstream bindings (msm8916) that have the "_clk" suffix in the
clock names. The downstream bindings also require it.
We want to drop the "_clk" suffix and at the same time support existing
bindings. Update the MDP5 code with the the msm_clk_get() helper to
support both old and new clock names.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 5694344db762..efde2d69ec09 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -511,7 +511,7 @@ static int get_clk(struct platform_device *pdev, struct clk
**clkp,
const char *name, bool mandatory)
{
struct device *dev = &pdev->dev;
- struct clk *clk = devm_clk_get(dev, name);
+ struct clk *clk = msm_clk_get(pdev, name);
if (IS_ERR(clk) && mandatory) {
dev_err(dev, "failed to get %s (%ld)\n", name, PTR_ERR(clk));
return PTR_ERR(clk);
@@ -896,22 +896,22 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
}
/* mandatory clocks: */
- ret = get_clk(pdev, &mdp5_kms->axi_clk, "bus_clk", true);
+ ret = get_clk(pdev, &mdp5_kms->axi_clk, "bus", true);
if (ret)
goto fail;
- ret = get_clk(pdev, &mdp5_kms->ahb_clk, "iface_clk", true);
+ ret = get_clk(pdev, &mdp5_kms->ahb_clk, "iface", true);
if (ret)
goto fail;
- ret = get_clk(pdev, &mdp5_kms->core_clk, "core_clk", true);
+ ret = get_clk(pdev, &mdp5_kms->core_clk, "core", true);
if (ret)
goto fail;
- ret = get_clk(pdev, &mdp5_kms->vsync_clk, "vsync_clk", true);
+ ret = get_clk(pdev, &mdp5_kms->vsync_clk, "vsync", true);
if (ret)
goto fail;
/* optional clocks: */
- get_clk(pdev, &mdp5_kms->lut_clk, "lut_clk", false);
- get_clk(pdev, &mdp5_kms->iommu_clk, "iommu_clk", false);
+ get_clk(pdev, &mdp5_kms->lut_clk, "lut", false);
+ get_clk(pdev, &mdp5_kms->iommu_clk, "iommu", false);
/* we need to set a default rate before enabling. Set a safe
* rate first, then figure out hw revision, and then set a
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers
Am 28.07.2017 um 03:43 schrieb Alex Deucher:
On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook wrote:
As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
designated initializers") mark other tableFunction entries with designated
initializers. The randstruct plugin requires designated initializers for
structures that are entirely function pointers.
Cc: Rex Zhu
Cc: Hawking Zhang
Cc: Alex Deucher
Signed-off-by: Kees Cook
---
If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
you think this is worth landing for v4.13, in which case, please take it
now. :)
Acked-by: Alex Deucher
I'm happy to take this through my tree if that is ok with you.
I'm wondering a bit how the plugin detects that it can randomize a
structure layout?
We have a couple of structs where this would be fatal.
Christian.
Alex
Thanks!
---
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 4c7f430b36eb..8e6cfd89c7e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -308,8 +308,8 @@ static int rv_tf_set_num_active_display(struct pp_hwmgr
*hwmgr, void *input,
}
static const struct phm_master_table_item rv_set_power_state_list[] = {
- { NULL, rv_tf_set_clock_limit },
- { NULL, rv_tf_set_num_active_display },
+ { .tableFunction = rv_tf_set_clock_limit },
+ { .tableFunction = rv_tf_set_num_active_display },
{ }
};
@@ -382,7 +382,7 @@ static int rv_tf_disable_gfx_off(struct pp_hwmgr *hwmgr,
}
static const struct phm_master_table_item rv_disable_dpm_list[] = {
- {NULL, rv_tf_disable_gfx_off},
+ { .tableFunction = rv_tf_disable_gfx_off },
{ },
};
@@ -407,7 +407,7 @@ static int rv_tf_enable_gfx_off(struct pp_hwmgr *hwmgr,
}
static const struct phm_master_table_item rv_enable_dpm_list[] = {
- {NULL, rv_tf_enable_gfx_off},
+ { .tableFunction = rv_tf_enable_gfx_off },
{ },
};
--
2.7.4
--
Kees Cook
Pixel Security
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #6 from Robin --- Thanks for the quick patches! I'm working my way to your kernel branch to rule out other changes fixing the issue. May take a little bit as I've not had to build my own kernels before. Anyway, going from 4.10 to the 4.13rc2 kernel found here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13-rc2/ Has the same problem, although slightly less reliably, and now including ring test errors. With less reliably I mean, I've seen the driver *sometimes* working a 2nd binding, but give the same error on the 3rd time. More results pending. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 10bit output via KMS
Hi, On 24 July 2017 at 14:56, Volker Vogelhuber wrote: I wonder if it is possible to have drmModeAddFB2 to handle 'X', 'R', '3', '0' at all. So is this supported in any way? Secondly, you're correct that you would need (theoretically) to extend drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in the last 10 years. This is the 'XR30' FourCC you mention, so it should already be there and working in the kernel. This question probably better fits to the drm mailing list, although the discussion started on the mesa list. I got it working now that my 10bit buffers are correctly displayed on a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0' fourcc code. Based on the Samsung's datasheet it should support 10bit signals, although the EDID does not seem to contain a vendor specific data block that would confirm that assumption. I have connected an Apollo Lake module with a display port cable to that display but I'm unsure if it's really 10bit or if there is some conversion logic somewhere in between that may downsample my 10 bit buffer to 8bit before sending it via displayport to the display. So far I stumbled over some patches regarding color management in the drm part of the kernel, but couldn't figure out how one could configure what is really send to the display. It seem to mostly be used to manipulate gamma values and so on. As the only indicator what is provided to the display is the buffer format handled by drmModeAddFB2 I doubt this is enough to configure the signal. Otherwise one could argue that the link speed of the display signal would have to toggle every time I send a different buffer format, which is certainly not the case. So what portion of the kms/drm chain do I miss currently? The drmModeModeInfo pointer has a clock field, but I guess this is meant to be for the pixel clock not the clock of the serialized signal. Probably that's why I couldn't find modelines for 4k@60 especially for 10bit compared to 8bit. Thanks Volker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()
On Thu, Jul 06, 2017 at 09:24:50PM +0200, Hans de Goede wrote: > intel_uncore_forcewake_reset() does forcewake puts and gets as such > we need to make sure that no-one tries to access the PUNIT->PMIC bus > (on systems where this bus is shared) while it runs, otherwise bad > things happen. > > Normally this is taken care of by the i915_pmic_bus_access_notifier() > which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other > driver tries to access the PMIC bus, so that later forcewake gets are > no-ops (for the duration of the bus access). > > But intel_uncore_forcewake_reset gets called in 3 cases: > 1) Before registering the pmic_bus_access_notifier > 2) After unregistering the pmic_bus_access_notifier > 3) To reset forcewake state on a GPU reset > > In all 3 cases the i915_pmic_bus_access_notifier() protection is > insufficient. This commit fixes the pmic bus access race this causes > by making intel_uncore_forcewake_reset() call iosf_mbi_punit_acquire() > (and iosf_mbi_punit_release() when done). > > Note that iosf_mbi_punit_acquire() locks a mutex and thus > intel_uncore_forcewake_reset() may sleep after this commit. I've checked > all callers and they all already take other mutexes, so this is not a > problem. > > Signed-off-by: Hans de Goede > --- > Changes in v2: > -Rebase on current (July 6th 2017) drm-next > --- > drivers/gpu/drm/i915/intel_uncore.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index 4a547cdfafa9..f9441c9ae226 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -237,6 +237,9 @@ static void intel_uncore_forcewake_reset(struct > drm_i915_private *dev_priv, > int retry_count = 100; > enum forcewake_domains fw, active_domains; > > + /* Acquire the PUNIT->PMIC bus before modifying forcewake settings */ > + iosf_mbi_punit_acquire(); > + > /* Hold uncore.lock across reset to prevent any register access >* with forcewake not set correctly. Wait until all pending >* timers are run before holding. > @@ -294,6 +297,7 @@ static void intel_uncore_forcewake_reset(struct > drm_i915_private *dev_priv, > assert_forcewakes_inactive(dev_priv); > > spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags); > + iosf_mbi_punit_release(); > } Looks ok in general, but during intel_uncore_suspend() and intel_uncore_fini() this still allows the following race: 1. (task 1) i915 MMIO access requiring forcewake, arms intel_uncore_fw_release_timer(). 2. (task 1) intel_uncore_suspend()->iosf_mbi_unregister_pmic_bus_access_notifier() 3. (task 2) DW I2C access start 4. (hrtimer irq) intel_uncore_fw_release_timer() does forcewake disable 5. (task 2) DW I2C access end One way to avoid this would be holding iosf_mbi_punit_mutex() around the whole iosf_mbi_unregister_pmic_bus_access_notifier() intel_uncore_forcewake_reset() sequence. --Imre > > static u64 gen9_edram_size(struct drm_i915_private *dev_priv) > -- > 2.13.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 Zoltan Boszormenyi (zbos...@pr.hu) changed: What|Removed |Added CC||zbos...@pr.hu --- Comment #75 from Zoltan Boszormenyi (zbos...@pr.hu) --- (In reply to Rich from comment #74) > Agree with the above. Not sure why such a huge regression has not just been > reverted until a suitable fix has been implemented. It seems the QA process has holes @ AMD. See bug #170741 , this is a regression since Linux 4.4-rc4 (not Radeon related). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 6/7] dt-bindings: display: rockchip: fill Documents for vop series
Hi Mark, Am Mittwoch, 26. Juli 2017, 14:19:35 CEST schrieb Mark Yao: > Signed-off-by: Mark Yao > Acked-by: Rob Herring > --- > Changes in v5: > - clean document commit title > - move changes description out of docummit commit msg > > Changes in v2: > - rename rk322x to rk3228 > - correct some vop registers define > > Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > index 9eb3f0a..5d835d9 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > @@ -8,8 +8,12 @@ Required properties: > - compatible: value should be one of the following > "rockchip,rk3036-vop"; > "rockchip,rk3288-vop"; > + "rockchip,rk3368-vop"; > + "rockchip,rk3366-vop"; > "rockchip,rk3399-vop-big"; > "rockchip,rk3399-vop-lit"; > + "rockchip,rk3228-vop"; > + "rockchip,rk3328-vop"; what is your ordering scheme here? As the number of rk socs will very likely increase in the future ordering alphanumerical might make everything more manageable when the list grows. So maybe swap rk3368 and rk3366 and move rk3228+rk3328 to sorted positions? Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6.1 4/7] drm/rockchip: vop: group vop registers
Am Freitag, 28. Juli 2017, 14:06:25 CEST schrieb Mark Yao: > Grouping the vop registers facilitates make register > definition clearer, and also is useful for different vop > reuse the same group register. > > Signed-off-by: Mark Yao > Reviewed-by: Jeffy Chen on rk3036 and rk3288 Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 Rich (f...@bitservices.org.uk) changed: What|Removed |Added CC||f...@bitservices.org.uk --- Comment #74 from Rich (f...@bitservices.org.uk) --- Agree with the above. Not sure why such a huge regression has not just been reverted until a suitable fix has been implemented. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled
Quoting Gustavo Padovan (2017-07-28 02:57:25)
> 2017-07-27 Chris Wilson :
>
> > Quoting Gustavo Padovan (2017-07-27 20:03:53)
> > > From: Gustavo Padovan
> > >
> > > If userspace already dropped its own reference by closing the sw_sync
> > > fence fd we might end up in a deadlock where
> > > dma_fence_is_signaled_locked() will trigger the release of the fence a
> > > thus try to hold the lock to remove the fence from the list.
> >
> > So the issue here is that call to dma_fence_is_signaled_lock() is
> > triggering the unreference?
>
> Exactly. I'll say that explicitely in the commit message.
:) It was more of a rhetorical question making sure that I understood
correctly.
> > But if I understand correctly, we just need to unlink first, then
> > signal.
> >
> > list_for_each_entry_safe() {
> > if (!timeline_fence_signaled(&pt->base))
> > break;
> >
> > list_del_init(&pt->link);
> > rb_erase(&pt->node, &obj->pt_tree);
> >
> > dma_fence_signal_locked(&pt->base);
> > }
> >
> > The challenge is in writing the comment to explain the open-coding.
>
> That is cleaner and doesn't need the get/put dance. I'll come up with a
> comment to explain it.
...
/*
* A signal callback may release the last reference to this fence,
* causing it to be freed. That operation has to be last to avoid
* a use after free inside this loop, and must be after we remove
* the fence from the timeline in order to prevent deadlocking on
* timeline->lock inside timeline_fence_release().
*/
dma_fence_signal_locked().
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
Hi,
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> struct vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and retrieve information about the gfx
> plane.
+ *
> + * Return: 0 on success, -errno on failure.
I think this should be more verbose, especially documenting that the
"guest driver didn't initialize the display yet" case isn't and error
and fields should be set to zero then (as discussed on the list).
> + */
> +struct vfio_device_gfx_plane_info {
> + __u32 argsz;
> + __u32 flags;
> + /* in */
> + __u32 drm_plane_type; /* type of plane:
> DRM_PLANE_TYPE_* */
> + /* out */
> + __u32 drm_format; /* drm format of plane */
> + __u64 drm_format_mod; /* tiled mode */
> + __u32 width;/* width of plane */
> + __u32 height; /* height of plane */
> + __u32 stride; /* stride of plane */
> + __u32 size; /* size of plane in bytes, align on
> page*/
> + __u32 x_pos;/* horizontal position of cursor plane,
> upper left corner in pixels */
> + __u32 y_pos;/* vertical position of cursor plane,
> upper left corner in lines*/
> + __u32 region_index;
> + __s32 fd; /* dma-buf fd */
> +};
Looks good to me.
Unfortunately I havn't been able to test the whole series yet due to
being busy with other stuff, and I'm about to leave for my summer
vacation. Will be back online on Aug 21st.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 552/789] ia64-linux-gcc: error: unrecognized command line option '-mhard-float'; did you mean '--warn-format'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 47c131e32afd3bec9905aa765331224d5c3d777c commit: 7d02ccb487d447a54d2dfe25213f2c014c298cc7 [552/789] drm/amdgpu/display: fix semicolon.cocci warnings config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 7d02ccb487d447a54d2dfe25213f2c014c298cc7 # save the attached .config to linux build tree make.cross ARCH=ia64 Note: the radeon-alex/amd-staging-drm-next HEAD 47c131e32afd3bec9905aa765331224d5c3d777c builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): >> ia64-linux-gcc: error: unrecognized command line option '-mhard-float'; did >> you mean '--warn-format'? >> ia64-linux-gcc: error: unrecognized command line option '-msse'; did you >> mean '-fdse'? >> ia64-linux-gcc: error: unrecognized command line option >> '-mpreferred-stack-boundary=4' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled
On Thu, Jul 27, 2017 at 04:03:53PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If userspace already dropped its own reference by closing the sw_sync
> fence fd we might end up in a deadlock where
> dma_fence_is_signaled_locked() will trigger the release of the fence a
> thus try to hold the lock to remove the fence from the list.
>
> We need to grab a reference to the fence before calling into this chain if
> we want to avoid this issue.
>
> Cc: Chris Wilson
> Signed-off-by: Gustavo Padovan
Do we have a testcase for this?
-Daniel
> ---
> drivers/dma-buf/sw_sync.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index af1bc84..8291434 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -144,11 +144,16 @@ static void sync_timeline_signal(struct sync_timeline
> *obj, unsigned int inc)
> obj->value += inc;
>
> list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
> - if (!dma_fence_is_signaled_locked(&pt->base))
> + dma_fence_get(&pt->base);
> + if (!dma_fence_is_signaled_locked(&pt->base)) {
> + dma_fence_put(&pt->base);
> break;
> + }
>
> list_del_init(&pt->link);
> rb_erase(&pt->node, &obj->pt_tree);
> +
> + dma_fence_put(&pt->base);
> }
>
> spin_unlock_irq(&obj->lock);
> --
> 2.9.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/atomic: Interruptible locks for everyone!
Op 27-07-17 om 17:30 schreef Daniel Vetter: > On Thu, Jul 27, 2017 at 03:45:11PM +0100, Emil Velikov wrote: >> Hi Maarten >> >> On 27 July 2017 at 13:58, Maarten Lankhorst >> wrote: >>> drm_atomic_commit could previous have always failed when waits failed, >>> but locking was always done uninterruptibly. Add infrastructure to make >>> it possible for callers to choose interruptible locking, and convert the >>> 4 most common ioctl's to use it. >>> >>> All other atomic helpers can be converted when Daniel's "acquire_ctx >>> for everyone!" patch series lands. >>> >> There's a KMS locking documentation/example in drm_modeset_lock.c. >> Can you please update that as well? > Not sure what we should update there? As-is it still works for the > non-interruptible case. Or do you mean we should have an interruptible > variant of it too? > > Anyway, with the testcase added also for cursor and plane code, patches > 4&5 also get my Reviewed-by: Daniel Vetter > > Any reason you didn't convert the set_config path too? That's probably the > one most will be stuck in when something goes wrong ... Another one is the > various get* and setprop calls (but the later needs my patch series > first). > -Daniel I only did the ones I expect to be called most often by frequency. The atomic ioctl, pageflip, cursor update and setplane for overlays are likely to be done most. I think we could test all additions like that, perhaps even the interruptible backoff case, at least for the atomic ioctl. :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
