[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 Madis Liias changed: What|Removed |Added URL|http://www.topcomfort.com.u | |a | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/05234bef/attachment.html>
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 Topcomfort changed: What|Removed |Added URL||http://www.topcomfort.com.u ||a -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/99c0dcea/attachment.html>
[Bug 85351] 3.17-rc5 hangs on Supermicro X8DAH system
https://bugzilla.kernel.org/show_bug.cgi?id=85351 --- Comment #4 from Ralf-Peter Rohbeck --- I blacklisted mgag200 to fix it. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85351] 3.17-rc5 hangs on Supermicro X8DAH system
https://bugzilla.kernel.org/show_bug.cgi?id=85351 --- Comment #3 from Joseph Bisch --- Created attachment 217761 --> https://bugzilla.kernel.org/attachment.cgi?id=217761&action=edit kern.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85351] 3.17-rc5 hangs on Supermicro X8DAH system
https://bugzilla.kernel.org/show_bug.cgi?id=85351 Joseph Bisch changed: What|Removed |Added CC||joseph.bisch at hpe.com --- Comment #2 from Joseph Bisch --- Happens to me too with 4.5.3-2_bpo8+1 from Debian jessie-backports. Attaching kern.log, but relevant output is: May 26 16:31:39 bl460gen9-03 kernel: [ 57.554859] fb: switching to mgag200drmfb from simple May 26 16:31:39 bl460gen9-03 kernel: [ 57.802070] Console: switching to colour dummy device 80x25 May 26 16:31:39 bl460gen9-03 kernel: [ 58.075534] [drm:mgag200_driver_load [mgag200]] *ERROR* can't reserve VRAM May 26 16:31:39 bl460gen9-03 kernel: [ 58.402739] mgag200 :01:00.1: Fatal error during GPU init: -6 -- You are receiving this mail because: You are watching the assignee of the bug.
fsl-dcu not works on latest "drm-next"
On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to? What
>> > specifically is the endianess problem you are seeing, what are you seeing
>> > and what do you expect to see?
>>
>> The CPU is little endian and the device DCU is big endian, specified
>> big-endian in DTS,
>>
>> And here is my DTS and regmap_config,
>>
>> Specified "big-endian" in DTS,
>>
>> dcu: dcu at 2ce {
>> compatible = "fsl,ls1021a-dcu";
>> reg = <0x0 0x2ce 0x0 0x1>;
>> interrupts = ;
>> clocks = <&platform_clk 0>;
>> clock-names = "dcu";
>> big-endian;
>> status = "disabled";
>> };
>>
>> I can't tell the difference of "reg_format_endian" and " val_format_endian
>> ", so I had tried four conditions. And all failed.
>>
>> static const struct regmap_config fsl_dcu_regmap_config = {
>> .reg_bits = 32,
>> .reg_stride = 4,
>> .val_bits = 32,
>> .cache_type = REGCACHE_RBTREE,
>
> This needs to be a flat cache. See
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> or https://lkml.org/lkml/2016/3/24/281
> max_register also needs an appropriate value.
FWIW, the latest patch which addresses this issue is Patch 5/6 of this
patchset:
https://lkml.org/lkml/2016/4/19/617
Unfortunately, that patchset missed the 4.7 merge window. I still miss
an Ack for the first patch of this patchset. But should go into the next
release...
--
Stefan
[Bug 95545] [amdgpu][tonga] mplayer -vo=gl:yuv=2 causes VM fault
https://bugs.freedesktop.org/show_bug.cgi?id=95545 --- Comment #6 from Marek Olšák --- Using a difference context for SDMA doesn't help. Disabling the CE preamble seems to be the only solution. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/e95a8316/attachment.html>
[Bug 95545] [amdgpu][tonga] mplayer -vo=gl:yuv=2 causes VM fault
https://bugs.freedesktop.org/show_bug.cgi?id=95545 --- Comment #5 from Marek Olšák --- The problem is with the CE preamble which is sometimes skipped when it shouldn't be. SDMA IB submission somehow affects it. The workarounds are: - disable SDMA (bad) - disable CE preamble (not so bad) - execute SDMA in a different amdgpu context (not tested, just an idea I'll try next) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/c8fa9c8d/attachment.html>
[RFT v3] drm: use late_initcall() for amdkfd and radeon
To get KFD support in radeon we need the following
initialization to happen in this order, their
respective driver file that has its init routine
listed next to it:
0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c
Order is rather implicit, but these drivers can currently
only do so much given the amount of leg room available.
Below are the respective init routines and how they are
initialized:
arch/x86/kernel/pci-dma.c rootfs_initcall(pci_iommu_init);
drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);
When a driver is built-in module_init() folds to use
device_initcall(), and we have the following possible
orders:
#define pure_initcall(fn)__define_initcall(fn, 0)
#define core_initcall(fn)__define_initcall(fn, 1)
#define postcore_initcall(fn)__define_initcall(fn, 2)
#define arch_initcall(fn)__define_initcall(fn, 3)
#define subsys_initcall(fn) __define_initcall(fn, 4)
#define fs_initcall(fn) __define_initcall(fn, 5)
-
#define rootfs_initcall(fn) __define_initcall(fn, rootfs)
#define device_initcall(fn) __define_initcall(fn, 6)
#define late_initcall(fn)__define_initcall(fn, 7)
Since we start off from rootfs_initcall(), it gives us 3 more
levels of leg room to play with for order semantics, this isn't
enough to address all required levels of dependencies, this
is specially true given that AMD-KFD needs to be loaded before
the radeon driver -- -but this it not enforced by symbols.
If the AMD-KFD driver is not loaded prior to the radeon driver
because otherwise the radeon driver will not initialize the
AMD-KFD driver and you get no KFD functionality in userspace.
Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
Makefile") works around some of the possibe races between
the AMD IOMMU v2 and GPU drivers by changing the link order.
This is fragile, however its the bets we can do, given that
making the GPU drivers use late_initcall() would also implicate
a similar race between them. That possible race is fortunatley
addressed given that the drm Makefile currently has amdkfd
linked prior to radeon:
drivers/gpu/drm/Makefile
...
obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
obj-$(CONFIG_DRM_RADEON)+= radeon/
...
Changing amdkfd and radeon to late_initcall() however is
still the right call in orde to annotate explicitly a
delayed dependency requirement between the GPU drivers
and the IOMMUs.
We can't address the fragile nature of the link order
right now, but in the future that might be possible.
Signed-off-by: Luis R. Rodriguez
---
Please note, the changes to drivers/Makefile are just
for the sake of forcing the possible race to occur,
if this works well the actual [PATCH] submission will
skip those changes as its pointless to remove those
work arounds as it stands, due to the limited nature
of the levels available for addressing requirements.
Also, if you are aware of further dependency hell
things like these -- please do let me know as I am
interested in looking at addressing them.
drivers/Makefile| 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 0b6f3d60193d..0fbe3982041f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,10 +50,7 @@ obj-$(CONFIG_RESET_CONTROLLER) += reset/
obj-y += tty/
obj-y += char/
-# iommu/ comes before gpu as gpu are using iommu controllers
-obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
-
-# gpu/ comes after char for AGP vs DRM startup and after iommu
+# gpu/ comes after char for AGP vs DRM startup
obj-y += gpu/
obj-$(CONFIG_CONNECTOR)+= connector/
@@ -147,6 +144,7 @@ obj-y += clk/
obj-$(CONFIG_MAILBOX) += mailbox/
obj-$(CONFIG_HWSPINLOCK) += hwspinlock/
+obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
obj-$(CONFIG_REMOTEPROC) += remoteproc/
obj-$(CONFIG_RPMSG)+= rpmsg/
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 850a5623661f..3d1dab8a31c7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -141,7 +141,7 @@ static void __exit kfd_module_exit(void)
dev_info(kfd_device, "Removed module\n");
}
-module_init(kfd_module_init);
+late_initcall(kfd_module_init);
module_exit(kfd_module_exit);
MODULE_AUTHOR(KFD_DRIVER_AUTHOR);
diff --gi
[PATCH 3/3] drm/amdgpu: fix pplib finish bug
From: Monk Liu
1,should use late_fini to kfree all resource otherwise
the released pointer maybe accessed in IRQ ip fini routine.
2,hwmgr should not be kfree by pem_fini which is invoked
by hw fini path.
Signed-off-by: Monk Liu
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 7 ---
drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c | 3 ---
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index bb8b149..1996670 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1325,6 +1325,11 @@ static int amdgpu_fini(struct amdgpu_device *adev)
adev->ip_block_status[i].valid = false;
}
+ for (i = adev->num_ip_blocks - 1; i >= 0; i--) {
+ if (adev->ip_blocks[i].funcs->late_fini)
+ adev->ip_blocks[i].funcs->late_fini((void *)adev);
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
index 1cd53c6..10b1be5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
@@ -183,13 +183,6 @@ static int amdgpu_pp_sw_fini(void *handle)
if (ret)
return ret;
-#ifdef CONFIG_DRM_AMD_POWERPLAY
- if (adev->pp_enabled) {
- amdgpu_pm_sysfs_fini(adev);
- amd_powerplay_fini(adev->powerplay.pp_handle);
- }
-#endif
-
return ret;
}
diff --git a/drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
b/drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
index 46410e3..fb88e4e 100644
--- a/drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
@@ -58,9 +58,6 @@ static void pem_fini(struct pp_eventmgr *eventmgr)
pem_unregister_interrupts(eventmgr);
pem_handle_event(eventmgr, AMD_PP_EVENT_UNINITIALIZE, &event_data);
-
- if (eventmgr != NULL)
- kfree(eventmgr);
}
int eventmgr_init(struct pp_instance *handle)
--
2.5.5
[PATCH 2/3] drm/amdgpu: impl late_fini for amdgpu_pp_ip
From: Monk Liu
This implements late_init support for powerplay.
Signed-off-by: Monk Liu
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
index 6bd961f..1cd53c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c
@@ -223,6 +223,22 @@ static int amdgpu_pp_hw_fini(void *handle)
return ret;
}
+static void amdgpu_pp_late_fini(void *handle)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+#ifdef CONFIG_DRM_AMD_POWERPLAY
+ if (adev->pp_enabled) {
+ amdgpu_pm_sysfs_fini(adev);
+ amd_powerplay_fini(adev->powerplay.pp_handle);
+ }
+
+ if (adev->powerplay.ip_funcs->late_fini)
+ adev->powerplay.ip_funcs->late_fini(
+ adev->powerplay.pp_handle);
+#endif
+}
+
static int amdgpu_pp_suspend(void *handle)
{
int ret = 0;
@@ -311,6 +327,7 @@ const struct amd_ip_funcs amdgpu_pp_ip_funcs = {
.sw_fini = amdgpu_pp_sw_fini,
.hw_init = amdgpu_pp_hw_init,
.hw_fini = amdgpu_pp_hw_fini,
+ .late_fini = amdgpu_pp_late_fini,
.suspend = amdgpu_pp_suspend,
.resume = amdgpu_pp_resume,
.is_idle = amdgpu_pp_is_idle,
--
2.5.5
[PATCH 1/3] drm/amdgpu: add late_fini for ip_funcs
From: Monk Liu
This give IP modules an optional late cleanup
function. This is needed to handle tricky inter-module
dependencies during tear down.
Signed-off-by: Monk Liu
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 6080951..afce1ed 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -157,6 +157,7 @@ struct amd_ip_funcs {
int (*hw_init)(void *handle);
/* tears down the hw state */
int (*hw_fini)(void *handle);
+ void (*late_fini)(void *handle);
/* handles IP specific hw/sw changes for suspend */
int (*suspend)(void *handle);
/* handles IP specific hw/sw changes for resume */
--
2.5.5
[PATCH 0/3] fix module unloading with powerplay enabled
This patch set fixes module unloading when powerplay is enabled. The issue is a dependency between the the IH (interrupt handler) IP module and the powerplay (power management) IP modules. The IH module may call back into other IP modules to disable interrupt sources after the other modules have already been torn down. This adds a new late_fini callback to avoid freeing the necessary bits in powerplay before the IH module has finished. Monk Liu (3): drm/amdgpu: add late_fini for ip_funcs drm/amdgpu: impl late_fini for amdgpu_pp_ip drm/amdgpu: fix pplib finish bug drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 24 --- drivers/gpu/drm/amd/include/amd_shared.h | 1 + drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c | 3 --- 4 files changed, 23 insertions(+), 10 deletions(-) -- 2.5.5
[PATCH] drm/amdgpu/gfx8: Add serdes wait for idle in CGCG en/disable
From: Tom St Denis Must wait for SERDES idle before exiting RLC SAFEMODE Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c index 494104e..b78fdbe 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c @@ -5780,6 +5780,8 @@ static void gfx_v8_0_update_coarse_grain_clock_gating(struct amdgpu_device *adev WREG32(mmRLC_CGCG_CGLS_CTRL, data); } + gfx_v8_0_wait_for_rlc_serdes(adev); + adev->gfx.rlc.funcs->exit_safe_mode(adev); } static int gfx_v8_0_update_gfx_clock_gating(struct amdgpu_device *adev, -- 2.5.5
[PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.
Hi Javier, On 05/24/2016 01:01 PM, Yakir Yang wrote: > Hi all, > > This series have been posted about one month, still no comments, help here :( This series works rightly on Rockchip platform, and most of them haven't touch the common analogix_dp driver (except for the hotplug fixed). So i guess Exynos platform should also happy with this changes. But not sure about that. So, is it possible that you could help to check this on Exynos Chromebook, if so i would be very grateful about that. Thanks, - Yakir > > RK3399 and RK3288 shared the same eDP IP controller, only some light > difference with VOP configure and GRF configure. > > Also same misc fix to analogix_dp driver: > - Hotplug invalid which report by Dan Carpenter > - Make panel detect to an optional action > - correct the register bit define error in ANALOGIX_DP_PLL_REG_1 > > > Changes in v2: > - new patch in v2 > - rebase with drm-next, fix some conflicts > - new patch in v2 > > Yakir Yang (10): >drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP >drm/rockchip: analogix_dp: split the lcdc select setting into device > data >drm/bridge: analogix_dp: correct the register bit define error in > ANALOGIX_DP_PLL_REG_1 >drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit > setting >drm/rockchip: analogix_dp: add rk3399 eDP support >drm/rockchip: analogix_dp: make panel detect to an optional action >drm/bridge: analogix_dp: introduce connector mode_valid callback to > plat driver >drm/rockchip: analogix_dp: correct the connector display color format > and bpc >drm/rockchip: analogix_dp: update the comments about why need to > hardcode VOP output mode >drm/bridge: analogix_dp: fix no drm hpd event when panel plug in > > .../bindings/display/bridge/analogix_dp.txt| 1 + > .../display/rockchip/analogix_dp-rockchip.txt | 2 +- > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 19 ++- > drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 +- > drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 12 +- > drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 5 +- > drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 157 > ++--- > include/drm/bridge/analogix_dp.h | 10 ++ > 8 files changed, 152 insertions(+), 62 deletions(-) >
[PATCH] drm/mediatek: mtk_dsi: Remove spurious drm_connector_unregister
Connectors are unregistered by mtk_drm_drv via drm_connector_unregister_all().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2d808e5..7695591 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -695,10 +695,8 @@ static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi)
{
drm_encoder_cleanup(&dsi->encoder);
/* Skip connector cleanup if creation was delegated to the bridge */
- if (dsi->conn.dev) {
- drm_connector_unregister(&dsi->conn);
+ if (dsi->conn.dev)
drm_connector_cleanup(&dsi->conn);
- }
}
static void mtk_dsi_ddp_start(struct mtk_ddp_comp *comp)
--
2.8.1
[PATCH] drm/mediatek: mtk_dpi: remove invalid error message
Do not try to dereference dpi if it is NULL.
Since dpi can never be NULL when mtk_dpi_set_display_mode() is called,
remove the message.
Reported-by: Heinrich Schuchardt
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d05ca79..0186e50 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -432,11 +432,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
unsigned long pll_rate;
unsigned int factor;
- if (!dpi) {
- dev_err(dpi->dev, "invalid argument\n");
- return -EINVAL;
- }
-
pix_rate = 1000UL * mode->clock;
if (mode->clock <= 74000)
factor = 8 * 3;
--
2.8.1
[PATCH v16 4/4] dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
Add an optional ddc-i2c-bus phandle property that points to an I2C master controller that handles the connector DDC pins. Signed-off-by: Philipp Zabel Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/connector/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt index acd5668..508aee4 100644 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt @@ -8,6 +8,7 @@ Required properties: Optional properties: - label: a symbolic name for the connector - hpd-gpios: HPD GPIO number +- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing Required nodes: - Video port for HDMI input -- 2.8.1
[PATCH v16 3/4] drm/mediatek: enable hdmi output control bit
From: Jie Qiu
MT8173 HDMI hardware has a output control bit to enable/disable HDMI
output. Because of security reason, so this bit can ONLY be controlled
in ARM supervisor mode. Now the only way to enter ARM supervisor is the
ARM trusted firmware. So atf provides a API for HDMI driver to call to
setup this HDMI control bit to enable HDMI output in supervisor mode.
Signed-off-by: Jie Qiu
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 12
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ec1ea4..ba812ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -230,6 +231,17 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
bool black)
static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
{
+ struct arm_smccc_res res;
+
+ /*
+* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
+* output. This bit can only be controlled in ARM supervisor mode.
+* The ARM trusted firmware provides an API for the HDMI driver to set
+* this control bit to enable HDMI output in supervisor mode.
+*/
+ arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
+ 0, 0, 0, 0, 0, &res);
+
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index 209fbe1..a5cb07d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -234,4 +234,5 @@
#define MHL_SYNC_AUTO_EN BIT(30)
#define HDMI_PCLK_FREE_RUN BIT(31)
+#define MTK_SIP_SET_AUTHORIZED_SECURE_REG 0x8201
#endif
--
2.8.1
[PATCH v16 2/4] drm/mediatek: Add HDMI support
From: Jie Qiu
This patch adds drivers for the HDMI bridge connected to the DPI0
display subsystem function block, for the HDMI DDC block, and for
the HDMI PHY to support HDMI output.
This includes an interface to the generic hdmi-codec driver to start
or stop audio playback and to retrieve ELD (EDID like data) to limit the
supported audio formats to the HDMI sink capabilities.
Signed-off-by: Jie Qiu
Signed-off-by: Junzhi Zhao
Signed-off-by: Philipp Zabel
---
Changes since v15:
- Fix DDC idle polling, the SIFM_TRI bit is set when the ddc controller is busy
- Don't register the HDMI connector, the drm driver will do it
---
drivers/gpu/drm/mediatek/Kconfig |8 +
drivers/gpu/drm/mediatek/Makefile |7 +
drivers/gpu/drm/mediatek/mtk_cec.c | 265
drivers/gpu/drm/mediatek/mtk_cec.h | 26 +
drivers/gpu/drm/mediatek/mtk_hdmi.c| 1816
drivers/gpu/drm/mediatek/mtk_hdmi.h| 23 +
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c| 358 +
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 237
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 515 +++
9 files changed, 3255 insertions(+)
create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index eeefc97..a6898d5d 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -14,3 +14,11 @@ config DRM_MEDIATEK
The module will be called mediatek-drm
This driver provides kernel mode setting and
buffer management to userspace.
+
+config DRM_MEDIATEK_HDMI
+ tristate "DRM HDMI Support for Mediatek SoCs"
+ depends on DRM_MEDIATEK
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ select GENERIC_PHY
+ help
+ DRM/KMS HDMI driver for Mediatek SoCs
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 5fcf58e..bf2e5be 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -12,3 +12,10 @@ mediatek-drm-y := mtk_disp_ovl.o \
mtk_dpi.o
obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
+
+mediatek-drm-hdmi-objs := mtk_cec.o \
+ mtk_hdmi.o \
+ mtk_hdmi_ddc.o \
+ mtk_mt8173_hdmi_phy.o
+
+obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c
b/drivers/gpu/drm/mediatek/mtk_cec.c
new file mode 100644
index 000..7a3eb8c
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Jie Qiu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_cec.h"
+
+#define TR_CONFIG 0x00
+#define CLEAR_CEC_IRQ BIT(15)
+
+#define CEC_CKGEN 0x04
+#define CEC_32K_PDNBIT(19)
+#define PDNBIT(16)
+
+#define RX_EVENT 0x54
+#define HDMI_PORD BIT(25)
+#define HDMI_HTPLG BIT(24)
+#define HDMI_PORD_INT_EN BIT(9)
+#define HDMI_HTPLG_INT_EN BIT(8)
+
+#define RX_GEN_WD 0x58
+#define HDMI_PORD_INT_32K_STATUS BIT(26)
+#define RX_RISC_INT_32K_STATUS BIT(25)
+#define HDMI_HTPLG_INT_32K_STATUS BIT(24)
+#define HDMI_PORD_INT_32K_CLR BIT(18)
+#define RX_INT_32K_CLR BIT(17)
+#define HDMI_HTPLG_INT_32K_CLR BIT(16)
+#define HDMI_PORD_INT_32K_STA_MASK BIT(10)
+#define RX_RISC_INT_32K_STA_MASK BIT(9)
+#define HDMI_HTPLG_INT_32K_STA_MASKBIT(8)
+#define HDMI_PORD_INT_32K_EN BIT(2)
+#define RX_INT_32K_EN BIT(1)
+#define HDMI_HTPLG_INT_32K_EN BIT(0)
+
+#define NORMAL_INT_CTRL0x5C
+#define HDMI_HTPLG_INT_STA BIT(0)
+#define HDMI_PORD_INT_STA BIT(1)
+#define HDMI_HTPLG_INT_CLR BIT(16)
+#define HDMI_PORD_INT_CLR BIT(17)
+#define HDMI_FULL_INT_CLR BIT(20)
+
+struct mtk_cec {
+ void __iomem *reg
[PATCH v16 1/4] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
Add the device tree binding documentation for Mediatek HDMI,
HDMI PHY and HDMI DDC devices.
Signed-off-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/display/mediatek/mediatek,hdmi.txt| 148 +
1 file changed, 148 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
new file mode 100644
index 000..7b12424
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
@@ -0,0 +1,148 @@
+Mediatek HDMI Encoder
+=
+
+The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
+its parallel input.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi".
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
+- phys: phandle link to the HDMI PHY node.
+ See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
+- phy-names: must contain "hdmi"
+- mediatek,syscon-hdmi: phandle link and register offset to the system
+ configuration registers. For mt8173 this must be offset 0x900 into the
+ MMSYS_CONFIG region: <&mmsys 0x900>.
+- ports: A node containing input and output port nodes with endpoint
+ definitions as documented in Documentation/devicetree/bindings/graph.txt.
+- port at 0: The input port in the ports node should be connected to a DPI
output
+ port.
+- port at 1: The output port in the ports node should be connected to the input
+ port of a connector node that contains a ddc-i2c-bus property, or to the
+ input port of an attached bridge chip, such as a SlimPort transmitter.
+
+HDMI CEC
+
+
+The HDMI CEC controller handles hotplug detection and CEC communication.
+
+Required properties:
+- compatible: Should be "mediatek,-cec"
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clock
+
+HDMI DDC
+
+
+The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi-ddc"
+- reg: Physical base address and length of the controller's registers
+- clocks: device clock
+- clock-names: Should be "ddc-i2c".
+
+HDMI PHY
+
+
+The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+output and drives the HDMI pads.
+
+Required properties:
+- compatible: "mediatek,-hdmi-phy"
+- reg: Physical base address and length of the module's registers
+- clocks: PLL reference clock
+- clock-names: must contain "pll_ref"
+- clock-output-names: must be "hdmitx_dig_cts" on mt8173
+- #phy-cells: must be <0>
+- #clock-cells: must be <0>
+
+Optional properties:
+- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
+- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+
+Example:
+
+cec: cec at 10013000 {
+ compatible = "mediatek,mt8173-cec";
+ reg = <0 0x10013000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+};
+
+hdmi_phy: hdmi-phy at 10209100 {
+ compatible = "mediatek,mt8173-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ clock-output-names = "hdmitx_dig_cts";
+ mediatek,ibias = <0xa>;
+ mediatek,ibias_up = <0x1c>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+};
+
+hdmi_ddc0: i2c at 11012000 {
+ compatible = "mediatek,mt8173-hdmi-ddc";
+ reg = <0 0x11012000 0 0x1c>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_I2C5>;
+ clock-names = "ddc-i2c";
+};
+
+hdmi0: hdmi at 14025000 {
+ compatible = "mediatek,mt8173-hdmi";
+ reg = <0 0x14025000 0 0x400>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+<&mmsys CLK_MM_HDMI_PLLCK>,
+<&mmsys CLK_MM_HDMI_AUDIO>,
+<&mmsys CLK_MM_HDMI_SPDIF>;
+ clock-names = "pixel", "pll", "bclk", "spdif";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pin>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ mediatek,syscon-hdmi = <&mmsys 0x900>;
+ assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
+ assigned-clock-parents = <&hdmi_phy>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ hdmi0_in: endpoint {
+ remote-endpoint = <&dpi0_out>;
+
[PATCH v16 0/4] MT8173 HDMI support
This series contains the MT8173 HDMI encoder, PHY, and DDC drivers. Changes since v15: - Fix DDC idle polling, the SIFM_TRI bit is set when the ddc controller is busy. - Don't register the HDMI connector, mtk_drm_drv will do it using drm_connector_register_all(). - Drop device tree patches, these will be submitted separately. regards Philipp Jie Qiu (2): drm/mediatek: Add HDMI support drm/mediatek: enable hdmi output control bit Philipp Zabel (2): dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation .../bindings/display/connector/hdmi-connector.txt |1 + .../bindings/display/mediatek/mediatek,hdmi.txt| 148 ++ drivers/gpu/drm/mediatek/Kconfig |8 + drivers/gpu/drm/mediatek/Makefile |7 + drivers/gpu/drm/mediatek/mtk_cec.c | 265 +++ drivers/gpu/drm/mediatek/mtk_cec.h | 26 + drivers/gpu/drm/mediatek/mtk_hdmi.c| 1828 drivers/gpu/drm/mediatek/mtk_hdmi.h| 23 + drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c| 358 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 238 +++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 515 ++ 11 files changed, 3417 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.c create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c -- 2.8.1
Regression in i915 in kernel 4.6.0-git - bisected to f21a21983ef13a031
The latest mainline kernel (commit 3f59de0) shows a regression. The symptom is
that as soon as the kernel is started, the display is blanked, and it is never
turned on again. This problem was bisected to commit
f21a21983ef13a031250c4c3f6018e29a549d0f1
("drm/i915: Splitting intel_dp_detect"). The adapter in question is the
integrated graphics controller on a Toshiba Tecra A50 laptop. The output of
"lspci -nnv" for that controller is as follows:
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA
controller])
Subsystem: Toshiba America Info Systems Device [1179:0002]
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at e000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 4000 [size=64]
Expansion ROM at [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915
If the kernel is booted with "nomodeset", the display is normal.
I will be happy to test any patches, or to answer any further questions.
Thanks,
Larry
[PATCH 2/2] drm/edid: Add 6 bpc quirk for display AEO model 0.
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.
A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.
The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.
Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.
Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.
This patch should be backported to stable.
Signed-off-by: Mario Kleiner
Cc: stable at vger.kernel.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7df26d4..2cb472b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -74,6 +74,8 @@
#define EDID_QUIRK_FORCE_8BPC (1 << 8)
/* Force 12bpc */
#define EDID_QUIRK_FORCE_12BPC (1 << 9)
+/* Force 6bpc */
+#define EDID_QUIRK_FORCE_6BPC (1 << 10)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -100,6 +102,9 @@ static struct edid_quirk {
/* Unknown Acer */
{ "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
+ /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
+ { "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
@@ -4082,6 +4087,9 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
drm_add_display_info(edid, &connector->display_info, connector);
+ if (quirks & EDID_QUIRK_FORCE_6BPC)
+ connector->display_info.bpc = 6;
+
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
--
2.7.0
[PATCH 1/2] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
This reverts commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.
Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.
The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.
DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.
Please backport to stable.
Signed-off-by: Mario Kleiner
Acked-by: Jani Nikula
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 46f9be3..3a57fa1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12066,21 +12066,11 @@ connected_sink_compute_bpp(struct intel_connector
*connector,
pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
}
- /* Clamp bpp to default limit on screens without EDID 1.4 */
- if (connector->base.display_info.bpc == 0) {
- int type = connector->base.connector_type;
- int clamp_bpp = 24;
-
- /* Fall back to 18 bpp when DP sink capability is unknown. */
- if (type == DRM_MODE_CONNECTOR_DisplayPort ||
- type == DRM_MODE_CONNECTOR_eDP)
- clamp_bpp = 18;
-
- if (bpp > clamp_bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default
limit of %d\n",
- bpp, clamp_bpp);
- pipe_config->pipe_bpp = clamp_bpp;
- }
+ /* Clamp bpp to 8 on screens without EDID 1.4 */
+ if (connector->base.display_info.bpc == 0 && bpp > 24) {
+ DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
+ bpp);
+ pipe_config->pipe_bpp = 24;
}
}
--
2.7.0
EDID/DP color precision fixes on Intel hw for stable (v2)
Following Jani's advice, this series just fixes the stable kernel regressions for DP color precision on Intel by reverting Jani's commit and adding the edid 6 bpc quirk for the AEO 0 panel to fix the original fdo bug that triggered this. Minimal patches to allow easy backporting to affected stable kernels. I'll send out the patches with improved DP sink precision handling on top of these in a separate series later, once these have landed. thanks, -mario
[PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()
On Fri, May 27, 2016 at 01:07:33AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items. > > WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be used in > memory reclaim path. > > kfd_process_wq is used for delay destruction. A work item embedded in > kfd_process gets queued to kfd_process_wq and when it executes it > destroys and frees the containing kfd_process and thus itself. > > This requires a dedicated workqueue because a work item once queued, may > get freed at any point of time and any external entity cannot > flush the work item. So, in order to wait for such a work item, > it needs to be put on a dedicated workqueue. > > kfd_module_exit() calls kfd_process_destroy_wq which ensures that all > pending work items are finished before the module is removed. > > flush_workqueue is unnecessary since destroy_workqueue() itself calls > drain_workqueue() which flushes repeatedly till the workqueue becomes empty. > > Hence flush_workqueue has been removed. > > Signed-off-by: Bhaktipriya Shridhar Acked-by: Tejun Heo Thanks. -- tejun
[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
https://bugzilla.kernel.org/show_bug.cgi?id=88861 --- Comment #22 from Wilfried Klaebe --- The issue goes away too, then. I don't currently see any difference to when I reverted 704ab614ec12. Xorg comes up on boot like it also did with 4.5.4 (and 4.5.5). -- You are receiving this mail because: You are the assignee for the bug.
[PATCH libdrm] radeon: use SAMPLE_SPLIT=2 for better MSAA perf on EG/CM
From: Marek Olšák
---
radeon/radeon_surface.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5ec9745..1424660 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -957,8 +957,10 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
}
surf->stencil_tile_split = 64;
} else {
-/* tile split must be >= 256 for colorbuffer surfaces */
-surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
+/* tile split must be >= 256 for colorbuffer surfaces,
+ * SAMPLE_SPLIT = tile_split / (bpe * 64), the optimal value is 2
+ */
+surf->tile_split = MAX2(2 * surf->bpe * 64, 256);
if (surf->tile_split > 4096)
surf->tile_split = 4096;
}
--
2.7.4
[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()
On 05/26/16 13:17, Daniel Vetter wrote: > On Thu, May 26, 2016 at 11:35:44AM +0300, Jyri Sarha wrote: >> > Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a >> > workaround for errata that may break LCD1 channel if gamma tables >> > are in use. >> > >> > Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel >> > Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I >> > have not tested the change to i915 driver, only compiled it, but >> > functionally it should be exactly the same. >> > >> > [1] http://www.spinics.net/lists/dri-devel/msg108092.html > Btw for testing it would be awesome if you could take the color manager > igt testcase we have, and make it generic. Probably needs some > adjustments like skip tests when not all properties which are needed are > there. We should already auto-skip crc-based tests when that's not there, > so hopefully not too much work. > > This way we could start to have something like real validation tests for > all these atomic extensions and make sure things do work across drivers in > a uniform way. Tomeu and Robert have done this conversion work thus far, > with Daniel leading the effort (all cc'ed). Lionel has done the color mgmt > test. Well, the igt is totally new to me. I could take a look after our next internal release in 2-3 weeks from now. But, how about this series? Should I send a pull request directly to Dave Airlie to get this in drm-next? BR, Jyri
[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()
On 26/05/16 13:17, Daniel Vetter wrote: > On Thu, May 26, 2016 at 11:35:44AM +0300, Jyri Sarha wrote: >> Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a >> workaround for errata that may break LCD1 channel if gamma tables >> are in use. >> >> Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel >> Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I >> have not tested the change to i915 driver, only compiled it, but >> functionally it should be exactly the same. >> >> [1] http://www.spinics.net/lists/dri-devel/msg108092.html > > Btw for testing it would be awesome if you could take the color manager > igt testcase we have, and make it generic. Probably needs some > adjustments like skip tests when not all properties which are needed are > there. We should already auto-skip crc-based tests when that's not there, > so hopefully not too much work. > > This way we could start to have something like real validation tests for > all these atomic extensions and make sure things do work across drivers in > a uniform way. Tomeu and Robert have done this conversion work thus far, > with Daniel leading the effort (all cc'ed). Lionel has done the color mgmt > test. I agree. And I have on my todo to have a look again at igt. Last time I looked there were really no tests that could be ran on our platforms, and I didn't have time to look at it further. And for those interested, I added a simple py script to kmsxx for hacking with gamma: https://github.com/tomba/kmsxx/blob/master/py/gamma.py Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/4a6580ed/attachment.sig>
[PATCH] gpu: drm: amd: amdkfd: Remove create_workqueue()
On Fri, May 27, 2016 at 12:15:17AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > kfd_process_wq is used for delay destruction. A work item embedded in > kfd_process gets queued to kfd_process_wq and when it executes it > destroys and frees the containing kfd_process and thus itself. > > This requires a dedicated workqueue because a work item once queued, may > get freed at any point of time and any external entity cannot > flush the work item. So, in order to wait for such a work item, > it needs to be put on a dedicated workqueue. > > kfd_module_exit() calls kfd_process_destroy_wq which ensures that all > pending work items are finished before the module is removed. > > flush_workqueue is unnecessary since destroy_workqueue() itself calls > drain_workqueue() which flushes repeatedly till the workqueue becomes empty. > > Hence flush_workqueue has been removed. create_workqueue(NAME) maps to alloc_workqueue(NAME, WQ_MEM_RECLAIM, 1), so the change is effectively dropping WQ_MEM_RECLAIM and changing concurrency value from 1 to WQ_DFL_ACTIVE. It'd be nice to explain why these changes are safe and I think they're. It just needs explanations. > Signed-off-by: Bhaktipriya Shridhar Other than that, Acked-by: Tejun Heo Thanks. -- tejun
[Intel-gfx] [PATCH] drm: Store the plane's index
On Thu, May 26, 2016 at 10:34:57AM +0100, Chris Wilson wrote:
> Currently the plane's index is determined by walking the list of all
> planes in the mode and finding the position of that plane in the list. A
> linear walk, especially a linear walk within a linear walk as frequently
> conceived by i915.ko [O(N^2)] quickly comes to dominate profiles.
>
> The plane's index is constant for as long as no earlier planes are
> removed from the list. For most drivers, planes are static, determined
> at boot and then untouched until shutdown. Storing the index upon
> construction and then only walking the tail upon removal should
> be a major improvement for all.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Matt Roper
I've been wondering about the cost of these silly walks myself.
Patch looks sane to me
Reviewed-by: Ville Syrjälä
Same for crtcs?
> ---
> drivers/gpu/drm/drm_crtc.c | 38 +-
> include/drm/drm_crtc.h | 6 +-
> 2 files changed, 14 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3a0384cce4a2..00ee01126b6f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1302,7 +1302,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> plane->type = type;
>
> list_add_tail(&plane->head, &config->plane_list);
> - config->num_total_plane++;
> + plane->index = config->num_total_plane++;
> if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> config->num_overlay_plane++;
>
> @@ -1369,6 +1369,7 @@ EXPORT_SYMBOL(drm_plane_init);
> void drm_plane_cleanup(struct drm_plane *plane)
> {
> struct drm_device *dev = plane->dev;
> + struct drm_plane *other;
>
> drm_modeset_lock_all(dev);
> kfree(plane->format_types);
> @@ -1376,6 +1377,10 @@ void drm_plane_cleanup(struct drm_plane *plane)
>
> BUG_ON(list_empty(&plane->head));
>
> + other = list_next_entry(plane, head);
> + list_for_each_entry_from(other, &dev->mode_config.plane_list, head)
> + other->index--;
> +
> list_del(&plane->head);
> dev->mode_config.num_total_plane--;
> if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> @@ -1393,29 +1398,6 @@ void drm_plane_cleanup(struct drm_plane *plane)
> EXPORT_SYMBOL(drm_plane_cleanup);
>
> /**
> - * drm_plane_index - find the index of a registered plane
> - * @plane: plane to find index for
> - *
> - * Given a registered plane, return the index of that CRTC within a DRM
> - * device's list of planes.
> - */
> -unsigned int drm_plane_index(struct drm_plane *plane)
> -{
> - unsigned int index = 0;
> - struct drm_plane *tmp;
> -
> - drm_for_each_plane(tmp, plane->dev) {
> - if (tmp == plane)
> - return index;
> -
> - index++;
> - }
> -
> - BUG();
> -}
> -EXPORT_SYMBOL(drm_plane_index);
> -
> -/**
> * drm_plane_from_index - find the registered plane at an index
> * @dev: DRM device
> * @idx: index of registered plane to find for
> @@ -1427,13 +1409,11 @@ struct drm_plane *
> drm_plane_from_index(struct drm_device *dev, int idx)
> {
> struct drm_plane *plane;
> - unsigned int i = 0;
>
> - drm_for_each_plane(plane, dev) {
> - if (i == idx)
> + drm_for_each_plane(plane, dev)
> + if (idx == plane->index)
> return plane;
> - i++;
> - }
> +
> return NULL;
> }
> EXPORT_SYMBOL(drm_plane_from_index);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 9771428e1ba8..eda3b1b3d3b4 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1543,6 +1543,7 @@ struct drm_plane {
> struct drm_object_properties properties;
>
> enum drm_plane_type type;
> + unsigned index;
>
> const struct drm_plane_helper_funcs *helper_private;
>
> @@ -2316,7 +2317,10 @@ extern int drm_plane_init(struct drm_device *dev,
> const uint32_t *formats, unsigned int format_count,
> bool is_primary);
> extern void drm_plane_cleanup(struct drm_plane *plane);
> -extern unsigned int drm_plane_index(struct drm_plane *plane);
> +static inline unsigned int drm_plane_index(struct drm_plane *plane)
> +{
> + return plane->index;
> +}
> extern struct drm_plane * drm_plane_from_index(struct drm_device *dev, int
> idx);
> extern void drm_plane_force_disable(struct drm_plane *plane);
> extern int drm_plane_check_pixel_format(const struct drm_plane *plane,
> --
> 2.8.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()
On 26/05/16 11:35, Jyri Sarha wrote: > Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a > workaround for errata that may break LCD1 channel if gamma tables > are in use. > > Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel > Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I > have not tested the change to i915 driver, only compiled it, but > functionally it should be exactly the same. Tested the v4, which should be identical to this one, on Panda, and works fine. This version looks good too: Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/329ad052/attachment.sig>
[PATCH] drm: Register the debugfs interfaces after loading the driver
On Thu, May 26, 2016 at 01:35:18PM +0100, Chris Wilson wrote: > In order to give the driver the chance to initialise the data structures > that will be exposed through debugfs, perform driver->load() before > registering the debugfs entries. (Otherwise it may be possible for > userspace to cause an oops through the debugfs interfaces.) As the > driver load is now before debugfs registration, make the registration > non-fatal (as it simply prevents us exposing an optional debug facility > and not hard ABI). The alternative here would be for i915.ko to stop registering a driver->debugfs_init and do it as part of its registration phase (like sysfs). -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning
On Wed, May 25, 2016 at 04:51:21PM -0700, Linus Torvalds wrote:
> On Wed, May 25, 2016 at 10:56 AM, Josh Poimboeuf
> wrote:
> >
> > I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to
> > skip warnings for specific instructions in inline asm:
> >
> > Here's an example of it how it was used:
>
> Ok, looking at that, I'm starting to suspect that it is simpler to
> just use STACK_FRAME_NON_STANDARD and mark the two functions that use
> this particular inline asm with the odd %rbp problem.
>
> It's a rather special case, after all.
That's fine with me, it is indeed a rare case. We can always add the
per-instruction macro later if needed. Here's a patch.
---
From: Josh Poimboeuf
Subject: [PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning
objtool reports the following warnings:
drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool: vmw_send_msg()+0x107:
duplicate frame pointer save
drivers/gpu/drm/vmwgfx/vmwgfx_msg.o: warning: objtool:
vmw_host_get_guestinfo()+0x252: duplicate frame pointer save
To quote Linus:
"The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
(a "rep outsb") to communicate with the hypervisor (it's a virtual GPU
driver for vmware), and %rbp is part of the communication. So the
inline asm does a save-and-restore of the frame pointer around the
instruction sequence.
I actually find the objtool warning to be quite reasonable, so it's
not exactly a false positive, since in this case it actually does
point out that the frame pointer won't be reliable over that
instruction sequence.
But in this particular case it just ends up being the wrong thing -
the code is what it is, and %rbp just can't have the frame information
due to annoying magic calling conventions."
Silence the warnings by telling objtool to ignore the two functions
which use the VMW_PORT_HB_{IN,OUT} macros.
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 6de283c..f0374f9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "drmP.h"
#include "vmwgfx_msg.h"
@@ -194,7 +195,7 @@ static int vmw_send_msg(struct rpc_channel *channel, const
char *msg)
return -EINVAL;
}
-
+STACK_FRAME_NON_STANDARD(vmw_send_msg);
/**
@@ -304,6 +305,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void
**msg,
return 0;
}
+STACK_FRAME_NON_STANDARD(vmw_recv_msg);
/**
--
2.4.11
[PATCH] drm: Register the debugfs interfaces after loading the driver
In order to give the driver the chance to initialise the data structures
that will be exposed through debugfs, perform driver->load() before
registering the debugfs entries. (Otherwise it may be possible for
userspace to cause an oops through the debugfs interfaces.) As the
driver load is now before debugfs registration, make the registration
non-fatal (as it simply prevents us exposing an optional debug facility
and not hard ABI).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_debugfs.c | 13 ++---
drivers/gpu/drm/drm_drv.c | 62 +++
2 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 3bcf8e6a85b3..8f36e014fbd2 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -160,10 +160,8 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
ret = drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
if (ret) {
- debugfs_remove(minor->debugfs_root);
- minor->debugfs_root = NULL;
DRM_ERROR("Failed to create core drm debugfs files\n");
- return ret;
+ goto err_root;
}
if (dev->driver->debugfs_init) {
@@ -171,10 +169,17 @@ int drm_debugfs_init(struct drm_minor *minor, int
minor_id,
if (ret) {
DRM_ERROR("DRM: Driver failed to initialize "
"/sys/kernel/debug/dri.\n");
- return ret;
+ goto err_core;
}
}
return 0;
+
+err_core:
+ drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
+err_root:
+ debugfs_remove(minor->debugfs_root);
+ minor->debugfs_root = NULL;
+ return ret;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index bff89226a344..82d1e80c2bf4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -307,15 +307,9 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
if (!minor)
return 0;
- ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
- if (ret) {
- DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
- return ret;
- }
-
ret = device_add(minor->kdev);
if (ret)
- goto err_debugfs;
+ return ret;
/* replace NULL with @minor so lookups will succeed from now on */
spin_lock_irqsave(&drm_minor_lock, flags);
@@ -324,10 +318,36 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
DRM_DEBUG("new minor registered %d\n", minor->index);
return 0;
+}
+
+static void drm_debugfs_register(struct drm_device *dev, unsigned int type)
+{
+ struct drm_minor *minor;
+
+ DRM_DEBUG("\n");
+ if (!drm_debugfs_root)
+ return;
+
+ minor = *drm_minor_get_slot(dev, type);
+ if (!minor)
+ return;
+
+ if (drm_debugfs_init(minor, minor->index, drm_debugfs_root))
+ DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
+}
+
+static void drm_debugfs_unregister(struct drm_device *dev, unsigned int type)
+{
+ struct drm_minor *minor;
+
+ if (!drm_debugfs_root)
+ return;
+
+ minor = *drm_minor_get_slot(dev, type);
+ if (!minor || !device_is_registered(minor->kdev))
+ return;
-err_debugfs:
drm_debugfs_cleanup(minor);
- return ret;
}
static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
@@ -346,7 +366,6 @@ static void drm_minor_unregister(struct drm_device *dev,
unsigned int type)
device_del(minor->kdev);
dev_set_drvdata(minor->kdev, NULL); /* safety belt */
- drm_debugfs_cleanup(minor);
}
/**
@@ -460,6 +479,10 @@ EXPORT_SYMBOL(drm_put_dev);
void drm_unplug_dev(struct drm_device *dev)
{
+ drm_debugfs_unregister(dev, DRM_MINOR_LEGACY);
+ drm_debugfs_unregister(dev, DRM_MINOR_RENDER);
+ drm_debugfs_unregister(dev, DRM_MINOR_CONTROL);
+
/* for a USB device */
drm_minor_unregister(dev, DRM_MINOR_LEGACY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
@@ -759,6 +782,10 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
goto err_minors;
}
+ drm_debugfs_register(dev, DRM_MINOR_CONTROL);
+ drm_debugfs_register(dev, DRM_MINOR_RENDER);
+ drm_debugfs_register(dev, DRM_MINOR_LEGACY);
+
ret = 0;
goto out_unlock;
@@ -800,6 +827,10 @@ void drm_dev_unregister(struct drm_device *dev)
list_for_each_entry_safe(r_list, list_temp, &dev->maplist, head)
drm_legacy_rmmap(dev, r_list->map);
+ drm_debugfs_unregiste
[PATCH] drm: Store the plane's index
Currently the plane's index is determined by walking the list of all
planes in the mode and finding the position of that plane in the list. A
linear walk, especially a linear walk within a linear walk as frequently
conceived by i915.ko [O(N^2)] quickly comes to dominate profiles.
The plane's index is constant for as long as no earlier planes are
removed from the list. For most drivers, planes are static, determined
at boot and then untouched until shutdown. Storing the index upon
construction and then only walking the tail upon removal should
be a major improvement for all.
v2: Convert drm_crtc_index() and drm_encoder_index() as well.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Matt Roper
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 98 ++
include/drm/drm_crtc.h | 25 ++--
2 files changed, 43 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d2a6d958ca76..4d978099aa17 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -692,7 +692,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
crtc->base.properties = &crtc->properties;
list_add_tail(&crtc->head, &config->crtc_list);
- config->num_crtc++;
+ crtc->index = config->num_crtc++;
crtc->primary = primary;
crtc->cursor = cursor;
@@ -721,6 +721,11 @@ EXPORT_SYMBOL(drm_crtc_init_with_planes);
void drm_crtc_cleanup(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
+ struct drm_crtc *other;
+
+ other = list_next_entry(crtc, head);
+ list_for_each_entry_from(other, &dev->mode_config.crtc_list, head)
+ other->index--;
kfree(crtc->gamma_store);
crtc->gamma_store = NULL;
@@ -741,29 +746,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
}
EXPORT_SYMBOL(drm_crtc_cleanup);
-/**
- * drm_crtc_index - find the index of a registered CRTC
- * @crtc: CRTC to find index for
- *
- * Given a registered CRTC, return the index of that CRTC within a DRM
- * device's list of CRTCs.
- */
-unsigned int drm_crtc_index(struct drm_crtc *crtc)
-{
- unsigned int index = 0;
- struct drm_crtc *tmp;
-
- drm_for_each_crtc(tmp, crtc->dev) {
- if (tmp == crtc)
- return index;
-
- index++;
- }
-
- BUG();
-}
-EXPORT_SYMBOL(drm_crtc_index);
-
/*
* drm_mode_remove - remove and free a mode
* @connector: connector list to modify
@@ -1166,7 +1148,7 @@ int drm_encoder_init(struct drm_device *dev,
}
list_add_tail(&encoder->head, &dev->mode_config.encoder_list);
- dev->mode_config.num_encoder++;
+ encoder->index = dev->mode_config.num_encoder++;
out_put:
if (ret)
@@ -1180,29 +1162,6 @@ out_unlock:
EXPORT_SYMBOL(drm_encoder_init);
/**
- * drm_encoder_index - find the index of a registered encoder
- * @encoder: encoder to find index for
- *
- * Given a registered encoder, return the index of that encoder within a DRM
- * device's list of encoders.
- */
-unsigned int drm_encoder_index(struct drm_encoder *encoder)
-{
- unsigned int index = 0;
- struct drm_encoder *tmp;
-
- drm_for_each_encoder(tmp, encoder->dev) {
- if (tmp == encoder)
- return index;
-
- index++;
- }
-
- BUG();
-}
-EXPORT_SYMBOL(drm_encoder_index);
-
-/**
* drm_encoder_cleanup - cleans up an initialised encoder
* @encoder: encoder to cleanup
*
@@ -1211,6 +1170,11 @@ EXPORT_SYMBOL(drm_encoder_index);
void drm_encoder_cleanup(struct drm_encoder *encoder)
{
struct drm_device *dev = encoder->dev;
+ struct drm_encoder *other;
+
+ other = list_next_entry(encoder, head);
+ list_for_each_entry_from(other, &dev->mode_config.encoder_list, head)
+ other->index--;
drm_modeset_lock_all(dev);
drm_mode_object_unregister(dev, &encoder->base);
@@ -1300,7 +1264,7 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
plane->type = type;
list_add_tail(&plane->head, &config->plane_list);
- config->num_total_plane++;
+ plane->index = config->num_total_plane++;
if (plane->type == DRM_PLANE_TYPE_OVERLAY)
config->num_overlay_plane++;
@@ -1367,6 +1331,7 @@ EXPORT_SYMBOL(drm_plane_init);
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane->dev;
+ struct drm_plane *other;
drm_modeset_lock_all(dev);
kfree(plane->format_types);
@@ -1374,6 +1339,10 @@ void drm_plane_cleanup(struct drm_plane *plane)
BUG_ON(list_empty(&plane->head));
+ other = list_next_entry(plane, head);
+ list_for_each_entry_from(other, &dev->mode_config.plane_list, head)
+ other->index--;
+
list_del(&plane->head);
dev->mode_config.num_total_p
[PATCH v5 1/4] drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()
On 05/26/16 12:05, Tomi Valkeinen wrote:
> Hi Jyri, Daniel,
>
> On 26/05/16 11:35, Jyri Sarha wrote:
>> Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt()
>> and update drm/i915-driver (the only user of the old function).
>>
>> The new function is more flexible. It allows driver to enable only the
>> features it has without forcing to enable all three color management
>> properties: degamma lut, csc matrix (ctm), and gamma lut.
>>
>> Suggested-by: Daniel Vetter
>> Signed-off-by: Jyri Sarha
>
>> +void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> +uint degamma_lut_size,
>> +bool has_ctm,
>> +uint gamma_lut_size)
>> +{
>> +struct drm_device *dev = crtc->dev;
>> +struct drm_mode_config *config = &dev->mode_config;
>> +
>> +if (degamma_lut_size) {
>> +drm_object_attach_property(&crtc->base,
>> + config->degamma_lut_property, 0);
>> +drm_object_attach_property(&crtc->base,
>> + config->degamma_lut_size_property,
>> + degamma_lut_size);
>> +}
>> +
>> +if (has_ctm)
>> +drm_object_attach_property(&crtc->base,
>> + config->ctm_property, 0);
>> +
>> +if (gamma_lut_size) {
>> +drm_object_attach_property(&crtc->base,
>> + config->gamma_lut_property, 0);
>> +drm_object_attach_property(&crtc->base,
>> + config->gamma_lut_size_property,
>> + gamma_lut_size);
>> +}
>> +}
>
> As I mentioned, I think it would make sense to call
> drm_mode_crtc_set_gamma_size() here. At least from omapdrm perspective.
>
> I had a look at i915, and that one looks a bit odd. It always sets
> drm_mode_crtc_set_gamma_size(256), but then only calls
> drm_helper_crtc_enable_color_mgmt() if
> INTEL_INFO(dev)->color.gamma_lut_size > 0, and gives gamma_lut_size as
> the size.
>
> Is there some legacy stuff at play here? drm_mode_crtc_set_gamma_size()
> should always be 256 (as X expects that), but the GAMMA_LUT property can
> give the real gamma lut size?
>
This indeed seems to be the case. If call drm_mode_crtc_set_gamma_size,
with 256, but set the gamma_lut_size_property to 1024, the X still works
but trough atomic API I can use the full length gamma table.
I wonder if should do yet one more patch-round?
BR,
Jyri
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/6ff45d39/attachment.sig>
[PATCH 2/2] drm/amdkfd: destroy dbgmgr in notifier release
amdkfd need to destroy the debug manager in case amdkfd's notifier
function is called before the unbind function, because in that case,
the unbind function will exit without destroying debug manager.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 248deb7..a1f41a7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -242,13 +242,19 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
pqm_uninit(&p->pqm);
/* Iterate over all process device data structure and check
-* if we should reset all wavefronts */
- list_for_each_entry(pdd, &p->per_device_data, per_device_list)
+* if we should delete debug managers and reset all wavefronts
+*/
+ list_for_each_entry(pdd, &p->per_device_data, per_device_list) {
+ if ((pdd->dev->dbgmgr) &&
+ (pdd->dev->dbgmgr->pasid == p->pasid))
+ kfd_dbgmgr_destroy(pdd->dev->dbgmgr);
+
if (pdd->reset_wavefronts) {
pr_warn("amdkfd: Resetting all wave fronts\n");
dbgdev_wave_reset_wavefronts(pdd->dev, p);
pdd->reset_wavefronts = false;
}
+ }
mutex_unlock(&p->mutex);
--
2.5.5
[PATCH 1/2] drm/amdkfd: unbind only existing processes
When unbinding a process from a device (initiated by amd_iommu_v2), the driver needs to make sure that process still exists in the process table. There is a possibility that amdkfd's own notifier handler - kfd_process_notifier_release() - was called before the unbind function and it already removed the process from the process table. Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index ac00579..248deb7 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -405,11 +405,17 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, unsigned int pasid) idx = srcu_read_lock(&kfd_processes_srcu); hash_for_each_rcu(kfd_processes_table, i, p, kfd_processes) - if (p->pasid == pasid) + if ((!p) || (p->pasid == pasid)) break; srcu_read_unlock(&kfd_processes_srcu, idx); + /* check if have a process in the hash. Maybe the relevant process was +* already erased in kfd_process_notifier_release() +*/ + if (!p) + return; + BUG_ON(p->pasid != pasid); mutex_lock(&p->mutex); -- 2.5.5
[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()
On Thu, May 26, 2016 at 11:35:44AM +0300, Jyri Sarha wrote:
> Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a
> workaround for errata that may break LCD1 channel if gamma tables
> are in use.
>
> Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel
> Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I
> have not tested the change to i915 driver, only compiled it, but
> functionally it should be exactly the same.
>
> [1] http://www.spinics.net/lists/dri-devel/msg108092.html
Btw for testing it would be awesome if you could take the color manager
igt testcase we have, and make it generic. Probably needs some
adjustments like skip tests when not all properties which are needed are
there. We should already auto-skip crc-based tests when that's not there,
so hopefully not too much work.
This way we could start to have something like real validation tests for
all these atomic extensions and make sure things do work across drivers in
a uniform way. Tomeu and Robert have done this conversion work thus far,
with Daniel leading the effort (all cc'ed). Lionel has done the color mgmt
test.
But probably simplest to chat a bit on #dri-devel about this.
-Daniel
>
> Changes from v4 to v5
> - No code changes
> - Reorder the patches so that color_mgmt-patch comes first
> - Fix some typos from commit descriptions
> - Squash:
> "drm: Add drm_crtc_enable_color_mgmt()",
> "drm/i915: Use drm_crtc_enable_color_mgmt()", and
> "drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()"
> to: "drm: drm_helper_crtc_enable_color_mgmt() =>
> drm_crtc_enable_color_mgmt()"
> - Squash:
> "drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties"
> into: "drm/omapdrm: Implement gamma_lut atomic crtc properties"
>
> Changes from v3 to v4
> - "drm/omapdrm: Add gamma table support to DSS dispc"
> - use interpolation code in dispc_mgr_set_gamma() to produce default lut
> - restore default lut table if NULL is given as gamma lut table
> - "drm/omapdrm: Implement gamma_lut atomic crtc property"
> - attach gamma_lut_property and gamma_lut_size_property to crtc if
> gamma tables are supported
> - restore default table if gamma lut property is deleted
> - Adds:
> - drm: Add drm_crtc_enable_color_mgmt()
> - drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties
> - drm/i915: Use drm_crtc_enable_color_mgmt()
> - drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()
>
> Changes from v2 to v3
> - "drm/omapdrm: Add gamma table support to DSS dispc"
> - fix dispc_init_gamma_tables() to always return an int
> - omap54xx_dispc_feats initializes .has_gamma_table not .has_gamma_tables
> - "drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc"
> - work-a-round -> workaround
> - Do not mention LOADMODE in description
> - dma_alloc_writecombine returns NULL on error
> - fix last wrong instrance of LCD output gating register
> - improve comment for framedone busy wait
> - add {} around busy loop's while statement
>
> Changes from v1 to v2
> - Drop "drm/omapdrm: omap_modeset_init: Separate crtc id and plane id
> indexing"
> - "drm/omapdrm: Add gamma table support to DSS dispc"
> - Address Tomi's comments here: https://patchwork.kernel.org/patch/9128629/
> - "drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc"
> - Address Tomi's comments here: https://patchwork.kernel.org/patch/9128633/
>
> Jyri Sarha (4):
> drm: drm_helper_crtc_enable_color_mgmt() =>
> drm_crtc_enable_color_mgmt()
> drm/omapdrm: Add gamma table support to DSS dispc
> drm/omapdrm: Workaround for errata i734 (LCD1 Gamma) in DSS dispc
> drm/omapdrm: Implement gamma_lut atomic crtc properties
>
> drivers/gpu/drm/drm_crtc.c| 45
> drivers/gpu/drm/drm_crtc_helper.c | 33 ---
> drivers/gpu/drm/i915/intel_color.c| 3 +-
> drivers/gpu/drm/omapdrm/dss/dispc.c | 374
> --
> drivers/gpu/drm/omapdrm/dss/dispc.h | 5 +
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 -
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 3 -
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 5 +
> drivers/gpu/drm/omapdrm/omap_crtc.c | 28 +++
> include/drm/drm_crtc.h| 5 +-
> include/drm/drm_crtc_helper.h | 3 -
> 11 files changed, 447 insertions(+), 60 deletions(-)
>
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v5 1/4] drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()
On Thu, May 26, 2016 at 12:59:09PM +0300, Jyri Sarha wrote:
> On 05/26/16 12:05, Tomi Valkeinen wrote:
> > Hi Jyri, Daniel,
> >
> > On 26/05/16 11:35, Jyri Sarha wrote:
> >> Add drm_crtc_enable_color_mgmt(), remove
> >> drm_helper_crtc_enable_color_mgmt()
> >> and update drm/i915-driver (the only user of the old function).
> >>
> >> The new function is more flexible. It allows driver to enable only the
> >> features it has without forcing to enable all three color management
> >> properties: degamma lut, csc matrix (ctm), and gamma lut.
> >>
> >> Suggested-by: Daniel Vetter
> >> Signed-off-by: Jyri Sarha
> >
> >> +void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >> + uint degamma_lut_size,
> >> + bool has_ctm,
> >> + uint gamma_lut_size)
> >> +{
> >> + struct drm_device *dev = crtc->dev;
> >> + struct drm_mode_config *config = &dev->mode_config;
> >> +
> >> + if (degamma_lut_size) {
> >> + drm_object_attach_property(&crtc->base,
> >> + config->degamma_lut_property, 0);
> >> + drm_object_attach_property(&crtc->base,
> >> + config->degamma_lut_size_property,
> >> + degamma_lut_size);
> >> + }
> >> +
> >> + if (has_ctm)
> >> + drm_object_attach_property(&crtc->base,
> >> + config->ctm_property, 0);
> >> +
> >> + if (gamma_lut_size) {
> >> + drm_object_attach_property(&crtc->base,
> >> + config->gamma_lut_property, 0);
> >> + drm_object_attach_property(&crtc->base,
> >> + config->gamma_lut_size_property,
> >> + gamma_lut_size);
> >> + }
> >> +}
> >
> > As I mentioned, I think it would make sense to call
> > drm_mode_crtc_set_gamma_size() here. At least from omapdrm perspective.
> >
> > I had a look at i915, and that one looks a bit odd. It always sets
> > drm_mode_crtc_set_gamma_size(256), but then only calls
> > drm_helper_crtc_enable_color_mgmt() if
> > INTEL_INFO(dev)->color.gamma_lut_size > 0, and gives gamma_lut_size as
> > the size.
> >
> > Is there some legacy stuff at play here? drm_mode_crtc_set_gamma_size()
> > should always be 256 (as X expects that), but the GAMMA_LUT property can
> > give the real gamma lut size?
> >
>
> This indeed seems to be the case. If call drm_mode_crtc_set_gamma_size,
> with 256, but set the gamma_lut_size_property to 1024, the X still works
> but trough atomic API I can use the full length gamma table.
>
> I wonder if should do yet one more patch-round?
The interaction between legacy gamma table and new atomic is a bit
ill-defined. But yeah I think the only valid value for legacy gamma table
is 256 afaik ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v5 1/4] drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()
Hi Jyri, Daniel,
On 26/05/16 11:35, Jyri Sarha wrote:
> Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt()
> and update drm/i915-driver (the only user of the old function).
>
> The new function is more flexible. It allows driver to enable only the
> features it has without forcing to enable all three color management
> properties: degamma lut, csc matrix (ctm), and gamma lut.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Jyri Sarha
> +void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> + uint degamma_lut_size,
> + bool has_ctm,
> + uint gamma_lut_size)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = &dev->mode_config;
> +
> + if (degamma_lut_size) {
> + drm_object_attach_property(&crtc->base,
> +config->degamma_lut_property, 0);
> + drm_object_attach_property(&crtc->base,
> +config->degamma_lut_size_property,
> +degamma_lut_size);
> + }
> +
> + if (has_ctm)
> + drm_object_attach_property(&crtc->base,
> +config->ctm_property, 0);
> +
> + if (gamma_lut_size) {
> + drm_object_attach_property(&crtc->base,
> +config->gamma_lut_property, 0);
> + drm_object_attach_property(&crtc->base,
> +config->gamma_lut_size_property,
> +gamma_lut_size);
> + }
> +}
As I mentioned, I think it would make sense to call
drm_mode_crtc_set_gamma_size() here. At least from omapdrm perspective.
I had a look at i915, and that one looks a bit odd. It always sets
drm_mode_crtc_set_gamma_size(256), but then only calls
drm_helper_crtc_enable_color_mgmt() if
INTEL_INFO(dev)->color.gamma_lut_size > 0, and gives gamma_lut_size as
the size.
Is there some legacy stuff at play here? drm_mode_crtc_set_gamma_size()
should always be 256 (as X expects that), but the GAMMA_LUT property can
give the real gamma lut size?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/1af86fc5/attachment-0001.sig>
[PATCH] drm/vmwgfx: fix "duplicate frame pointer save" warning
On Thu, May 26, 2016 at 11:43 AM, Josh Poimboeuf wrote: > > That's fine with me, it is indeed a rare case. We can always add the > per-instruction macro later if needed. Here's a patch. Ingo, I can take this directly, unless you have other things pending that you want to send anyway and would just add this to that existing pile. Just let me know. Linus
[PATCH 13/20] drm/bridge: Add RGB to VGA bridge support
Hi Rob, On Mon, May 16, 2016 at 09:07:18AM -0500, Rob Herring wrote: > On Mon, May 16, 2016 at 7:47 AM, Maxime Ripard > wrote: > > Some boards have an entirely passive RGB to VGA bridge, based on either > > DACs or resistor ladders. > > > > Those might or might not have an i2c bus routed to the VGA connector in > > order to access the screen EDIDs. > > > > Add a bridge that doesn't do anything but expose the modes available on the > > screen, either based on the EDIDs if available, or based on the XGA > > standards. > > > > Signed-off-by: Maxime Ripard > > --- > > .../bindings/display/bridge/dumb-vga.txt | 40 + > > drivers/gpu/drm/bridge/Kconfig | 6 + > > drivers/gpu/drm/bridge/Makefile| 1 + > > drivers/gpu/drm/bridge/dumb-vga.c | 186 > > + > > 4 files changed, 233 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/dumb-vga.txt > > create mode 100644 drivers/gpu/drm/bridge/dumb-vga.c > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt > > b/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt > > new file mode 100644 > > index ..757f04de97f3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga.txt > > @@ -0,0 +1,40 @@ > > +Passive RGB to VGA bridge > > +- > > + > > +This binding is aimed for entirely passive RGB to VGA bridges that do not > > +require any configuration. > > No reset or enable lines or regulators? On the three designs I've seen: - One doesn't need any of these - One has a GPIO enable pin but with it's resistor not populated - One has a regulator controlled by a GPIO So I guess in most cases, we don't need anything, but we still might to cover all cases. > > + > > +Required properties: > > + > > +- compatible: Should be "dumb-vga-bridge" > > + > > +Optional properties: > > + > > +- ddc-i2c-bus: phandle to the i2c bus used to communicate with the monitor > > The i2c bus is a property of the connector, not the bridge chip, so it > belongs in a VGA connector node (which we already have binding for). > > I think for the really "dumb" (or transparent case), you should only > have a connector. For anything more complex, then you should have both > a DAC and connector node. So, in essence, something like: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/r8a7794-alt.dts#n37 > On the driver side, I think we could handle multiple connectors with a > single driver. Ideally, that would work with any DRM driver that has a > connector node. I'm not sure what you mean by that. I really think it should be a separate driver in order to share the common code that so far the current implementations put in some driver specific code (even though it might be completely generic). Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/c56e1bc6/attachment-0001.sig>
[PATCH v5 4/4] drm/omapdrm: Implement gamma_lut atomic crtc properties
Implement gamma_lut atomic crtc properties, set crtc gamma size to 256
for all crtcs and use drm_atomic_helper_legacy_gamma_set() as
gamma_set func. The tv-out crtc has 1024 element gamma table (with
10bit precision) in HW, but current Xorg server does not accept
anything else but 256 elements so that is used for all CRTCs. The dss
dispc API converts table of any length for HW and uses linear
interpolation in the process. The default gamma table is restored
if gamma_lut property is deleted.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 075f2bb..e03b349 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -384,6 +384,19 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
WARN_ON(omap_crtc->vblank_irq.registered);
+ if (crtc->state->color_mgmt_changed) {
+ struct drm_color_lut *lut = NULL;
+ uint length = 0;
+
+ if (crtc->state->gamma_lut) {
+ lut = (struct drm_color_lut *)
+ crtc->state->gamma_lut->data;
+ length = crtc->state->gamma_lut->length /
+ sizeof(*lut);
+ }
+ dispc_mgr_set_gamma(omap_crtc->channel, lut, length);
+ }
+
if (dispc_mgr_is_enabled(omap_crtc->channel)) {
DBG("%s: GO", omap_crtc->name);
@@ -460,6 +473,7 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = omap_crtc_destroy,
.page_flip = drm_atomic_helper_page_flip,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
.set_property = drm_atomic_helper_crtc_set_property,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
@@ -534,6 +548,20 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
drm_crtc_helper_add(crtc, &omap_crtc_helper_funcs);
+ /* The dispc API adapts to what ever size, but the HW supports
+* 256 element gamma table for LCDs and 1024 element table for
+* OMAP_DSS_CHANNEL_DIGIT. X server assumes 256 element gamma
+* tables so lets use that. Size of HW gamma table can be
+* extracted with dispc_mgr_gamma_size(). If it returns 0
+* gamma table is not supprted.
+*/
+ if (dispc_mgr_gamma_size(channel)) {
+ uint gamma_lut_size = 256;
+
+ drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
+ drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
+ }
+
omap_plane_install_properties(crtc->primary, &crtc->base);
omap_crtcs[channel] = omap_crtc;
--
1.9.1
[PATCH v5 3/4] drm/omapdrm: Workaround for errata i734 (LCD1 Gamma) in DSS dispc
Workaround for errata i734 in DSS dispc
- LCD1 Gamma Correction Is Not Working When GFX Pipe Is Disabled
For gamma tables to work on LCD1 the GFX plane has to be used at least
once after DSS HW has come out of reset. The workaround sets up a
minimal LCD setup with GFX plane and waits for one vertical sync irq
before disabling the setup and continuing with the context
restore. The physical outputs are gated during the operation.
For details see:
OMAP543x Multimedia Device Silicon Revision 2.0 Silicon Errata
Literature Number: SWPZ037E
Or some other relevant errata document for the DSS IP version.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 174
1 file changed, 174 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index dbe5ab3..eff857f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -115,6 +115,8 @@ struct dispc_features {
bool reverse_ilace_field_order:1;
bool has_gamma_table:1;
+
+ bool has_gamma_i734_bug:1;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -4095,6 +4097,7 @@ static const struct dispc_features omap44xx_dispc_feats =
{
.supports_double_pixel = true,
.reverse_ilace_field_order =true,
.has_gamma_table= true,
+ .has_gamma_i734_bug = true,
};
static const struct dispc_features omap54xx_dispc_feats = {
@@ -4121,6 +4124,7 @@ static const struct dispc_features omap54xx_dispc_feats =
{
.supports_double_pixel = true,
.reverse_ilace_field_order =true,
.has_gamma_table= true,
+ .has_gamma_i734_bug = true,
};
static int dispc_init_features(struct platform_device *pdev)
@@ -4212,6 +4216,168 @@ void dispc_free_irq(void *dev_id)
}
EXPORT_SYMBOL(dispc_free_irq);
+/*
+ * Workaround for errata i734 in DSS dispc
+ * - LCD1 Gamma Correction Is Not Working When GFX Pipe Is Disabled
+ *
+ * For gamma tables to work on LCD1 the GFX plane has to be used at
+ * least once after DSS HW has come out of reset. The workaround
+ * sets up a minimal LCD setup with GFX plane and waits for one
+ * vertical sync irq before disabling the setup and continuing with
+ * the context restore. The physical outputs are gated during the
+ * operation. This workaround requires that gamma table's LOADMODE
+ * is set to 0x2 in DISPC_CONTROL1 register.
+ *
+ * For details see:
+ * OMAP543x Multimedia Device Silicon Revision 2.0 Silicon Errata
+ * Literature Number: SWPZ037E
+ * Or some other relevant errata document for the DSS IP version.
+ */
+
+static const struct dispc_errata_i734_data {
+ struct omap_video_timings timings;
+ struct omap_overlay_info ovli;
+ struct omap_overlay_manager_info mgri;
+ struct dss_lcd_mgr_config lcd_conf;
+} i734 = {
+ .timings = {
+ .x_res = 8, .y_res = 1,
+ .pixelclock = 1600,
+ .hsw = 8, .hfp = 4, .hbp = 4,
+ .vsw = 1, .vfp = 1, .vbp = 1,
+ .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .interlace = false,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .double_pixel = false,
+ },
+ .ovli = {
+ .screen_width = 1,
+ .width = 1, .height = 1,
+ .color_mode = OMAP_DSS_COLOR_RGB24U,
+ .rotation = OMAP_DSS_ROT_0,
+ .rotation_type = OMAP_DSS_ROT_DMA,
+ .mirror = 0,
+ .pos_x = 0, .pos_y = 0,
+ .out_width = 0, .out_height = 0,
+ .global_alpha = 0xff,
+ .pre_mult_alpha = 0,
+ .zorder = 0,
+ },
+ .mgri = {
+ .default_color = 0,
+ .trans_enabled = false,
+ .partial_alpha_enabled = false,
+ .cpr_enable = false,
+ },
+ .lcd_conf = {
+ .io_pad_mode = DSS_IO_PAD_MODE_BYPASS,
+ .stallmode = false,
+ .fifohandcheck = false,
+ .clock_info = {
+ .lck_div = 1,
+ .pck_div = 2,
+ },
+ .video_port_width = 24,
+ .lcden_sig_polarity = 0,
+ },
+};
+
+static struct i734_buf {
+ size_t size;
+ dma_addr_t paddr;
+ void *vaddr;
+} i734_buf;
+
+static int dispc_errata_i734_wa_init(void)
+{
+ if (!dispc.feat->has_gamma_i734_bug)
+ return 0;
+
+ i734_buf.size = i734.ovli.width * i734.ovli.height *
+ color_mode_to_bpp(i734.ovli.color_mode) / 8;
+
+ i734_buf.vaddr = dma_alloc_writecombine(&dispc.pdev->dev, i734_buf.size,
+
[PATCH v5 2/4] drm/omapdrm: Add gamma table support to DSS dispc
Add gamma table support to DSS dispc.
DSS driver initializes the default gamma table at component bind time
and holds a copy of all gamma tables in its internal data structure.
Each call to dispc_mgr_set_gamma() updates the internal table and
triggers write to the HW, if it is enabled. The tables are restored to
HW in PM resume callback. The drivers internal data structure match
the HW tables in size and in number of significant bits per color
component. The dispc_mgr_set_gamma() converts the size of any given
table for the internal data structure using linear interpolation.
Default gamma table is restored if NULL is given in place of gamma
lut.
dispc_mgr_gamma_size() gives HW gamma table size for the channel and
returns 0 if gamma table is not supported by the HW or the DSS driver.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 200 +++---
drivers/gpu/drm/omapdrm/dss/dispc.h | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 -
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 3 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 5 +
5 files changed, 194 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f83608b..dbe5ab3 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -113,9 +113,12 @@ struct dispc_features {
* never both, we can just use this flag for now.
*/
bool reverse_ilace_field_order:1;
+
+ bool has_gamma_table:1;
};
#define DISPC_MAX_NR_FIFOS 5
+#define DISPC_MAX_CHANNEL_GAMMA 4
static struct {
struct platform_device *pdev;
@@ -135,6 +138,8 @@ static struct {
boolctx_valid;
u32 ctx[DISPC_SZ_REGS / sizeof(u32)];
+ u32 *gamma_table[DISPC_MAX_CHANNEL_GAMMA];
+
const struct dispc_features *feat;
bool is_enabled;
@@ -178,11 +183,19 @@ struct dispc_reg_field {
u8 low;
};
+struct dispc_gamma_desc {
+ u32 len;
+ u32 bits;
+ u16 reg;
+ bool has_index;
+};
+
static const struct {
const char *name;
u32 vsync_irq;
u32 framedone_irq;
u32 sync_lost_irq;
+ struct dispc_gamma_desc gamma;
struct dispc_reg_field reg_desc[DISPC_MGR_FLD_NUM];
} mgr_desc[] = {
[OMAP_DSS_CHANNEL_LCD] = {
@@ -190,6 +203,12 @@ static const struct {
.vsync_irq = DISPC_IRQ_VSYNC,
.framedone_irq = DISPC_IRQ_FRAMEDONE,
.sync_lost_irq = DISPC_IRQ_SYNC_LOST,
+ .gamma = {
+ .len= 256,
+ .bits = 8,
+ .reg= DISPC_GAMMA_TABLE0,
+ .has_index = true,
+ },
.reg_desc = {
[DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 0,
0 },
[DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL, 3,
3 },
@@ -207,6 +226,12 @@ static const struct {
.vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
.framedone_irq = DISPC_IRQ_FRAMEDONETV,
.sync_lost_irq = DISPC_IRQ_SYNC_LOST_DIGIT,
+ .gamma = {
+ .len= 1024,
+ .bits = 10,
+ .reg= DISPC_GAMMA_TABLE2,
+ .has_index = false,
+ },
.reg_desc = {
[DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 1,
1 },
[DISPC_MGR_FLD_STNTFT] = { },
@@ -224,6 +249,12 @@ static const struct {
.vsync_irq = DISPC_IRQ_VSYNC2,
.framedone_irq = DISPC_IRQ_FRAMEDONE2,
.sync_lost_irq = DISPC_IRQ_SYNC_LOST2,
+ .gamma = {
+ .len= 256,
+ .bits = 8,
+ .reg= DISPC_GAMMA_TABLE1,
+ .has_index = true,
+ },
.reg_desc = {
[DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL2, 0,
0 },
[DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL2, 3,
3 },
@@ -241,6 +272,12 @@ static const struct {
.vsync_irq = DISPC_IRQ_VSYNC3,
.framedone_irq = DISPC_IRQ_FRAMEDONE3,
.sync_lost_irq = DISPC_IRQ_SYNC_LOST3,
+ .gamma = {
+ .len= 256,
+ .bits = 8,
+ .reg= DISPC_GAMMA_TABLE3,
+ .has_index = true,
+ },
.reg_desc = {
[DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL3, 0,
0 },
[DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL3, 3,
3 },
@@ -1084,20 +1121,6 @@ static u32 d
[PATCH v5 1/4] drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()
Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt()
and update drm/i915-driver (the only user of the old function).
The new function is more flexible. It allows driver to enable only the
features it has without forcing to enable all three color management
properties: degamma lut, csc matrix (ctm), and gamma lut.
Suggested-by: Daniel Vetter
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/drm_crtc.c | 45 ++
drivers/gpu/drm/drm_crtc_helper.c | 33
drivers/gpu/drm/i915/intel_color.c | 3 ++-
include/drm/drm_crtc.h | 5 -
include/drm/drm_crtc_helper.h | 3 ---
5 files changed, 51 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d2a6d95..b097226 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -6065,3 +6065,48 @@ struct drm_tile_group *drm_mode_create_tile_group(struct
drm_device *dev,
return tg;
}
EXPORT_SYMBOL(drm_mode_create_tile_group);
+
+/**
+ * drm_crtc_enable_color_mgmt - enable color management properties
+ * @crtc: DRM CRTC
+ * @degamma_lut_size: the size of the degamma lut (before CSC)
+ * @has_ctm: whether to attach ctm_property for CSC matrix
+ * @gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a CRTC. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
+ uint degamma_lut_size,
+ bool has_ctm,
+ uint gamma_lut_size)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (degamma_lut_size) {
+ drm_object_attach_property(&crtc->base,
+ config->degamma_lut_property, 0);
+ drm_object_attach_property(&crtc->base,
+ config->degamma_lut_size_property,
+ degamma_lut_size);
+ }
+
+ if (has_ctm)
+ drm_object_attach_property(&crtc->base,
+ config->ctm_property, 0);
+
+ if (gamma_lut_size) {
+ drm_object_attach_property(&crtc->base,
+ config->gamma_lut_property, 0);
+ drm_object_attach_property(&crtc->base,
+ config->gamma_lut_size_property,
+ gamma_lut_size);
+ }
+}
+EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a6e4243..bf10d70 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1121,36 +1121,3 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc,
int x, int y,
return drm_plane_helper_commit(plane, plane_state, old_fb);
}
EXPORT_SYMBOL(drm_helper_crtc_mode_set_base);
-
-/**
- * drm_helper_crtc_enable_color_mgmt - enable color management properties
- * @crtc: DRM CRTC
- * @degamma_lut_size: the size of the degamma lut (before CSC)
- * @gamma_lut_size: the size of the gamma lut (after CSC)
- *
- * This function lets the driver enable the color correction properties on a
- * CRTC. This includes 3 degamma, csc and gamma properties that userspace can
- * set and 2 size properties to inform the userspace of the lut sizes.
- */
-void drm_helper_crtc_enable_color_mgmt(struct drm_crtc *crtc,
- int degamma_lut_size,
- int gamma_lut_size)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_mode_config *config = &dev->mode_config;
-
- drm_object_attach_property(&crtc->base,
- config->degamma_lut_property, 0);
- drm_object_attach_property(&crtc->base,
- config->ctm_property, 0);
- drm_object_attach_property(&crtc->base,
- config->gamma_lut_property, 0);
-
- drm_object_attach_property(&crtc->base,
- config->degamma_lut_size_property,
- degamma_lut_size);
- drm_object_attach_property(&crtc->base,
- config->gamma_lut_size_property,
- gamma_lut_size);
-}
-EXPORT_SYMBOL(drm_helper_crtc_enable_color_mgmt);
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color
[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()
Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a
workaround for errata that may break LCD1 channel if gamma tables
are in use.
Also adds new drm_crtc_enable_color_mgmt() as suggested[1] by Daniel
Vetter and get rid of the old drm_helper_crtc_enable_color_mgmt(). I
have not tested the change to i915 driver, only compiled it, but
functionally it should be exactly the same.
[1] http://www.spinics.net/lists/dri-devel/msg108092.html
Changes from v4 to v5
- No code changes
- Reorder the patches so that color_mgmt-patch comes first
- Fix some typos from commit descriptions
- Squash:
"drm: Add drm_crtc_enable_color_mgmt()",
"drm/i915: Use drm_crtc_enable_color_mgmt()", and
"drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()"
to: "drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()"
- Squash:
"drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties"
into: "drm/omapdrm: Implement gamma_lut atomic crtc properties"
Changes from v3 to v4
- "drm/omapdrm: Add gamma table support to DSS dispc"
- use interpolation code in dispc_mgr_set_gamma() to produce default lut
- restore default lut table if NULL is given as gamma lut table
- "drm/omapdrm: Implement gamma_lut atomic crtc property"
- attach gamma_lut_property and gamma_lut_size_property to crtc if
gamma tables are supported
- restore default table if gamma lut property is deleted
- Adds:
- drm: Add drm_crtc_enable_color_mgmt()
- drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties
- drm/i915: Use drm_crtc_enable_color_mgmt()
- drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()
Changes from v2 to v3
- "drm/omapdrm: Add gamma table support to DSS dispc"
- fix dispc_init_gamma_tables() to always return an int
- omap54xx_dispc_feats initializes .has_gamma_table not .has_gamma_tables
- "drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc"
- work-a-round -> workaround
- Do not mention LOADMODE in description
- dma_alloc_writecombine returns NULL on error
- fix last wrong instrance of LCD output gating register
- improve comment for framedone busy wait
- add {} around busy loop's while statement
Changes from v1 to v2
- Drop "drm/omapdrm: omap_modeset_init: Separate crtc id and plane id indexing"
- "drm/omapdrm: Add gamma table support to DSS dispc"
- Address Tomi's comments here: https://patchwork.kernel.org/patch/9128629/
- "drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc"
- Address Tomi's comments here: https://patchwork.kernel.org/patch/9128633/
Jyri Sarha (4):
drm: drm_helper_crtc_enable_color_mgmt() =>
drm_crtc_enable_color_mgmt()
drm/omapdrm: Add gamma table support to DSS dispc
drm/omapdrm: Workaround for errata i734 (LCD1 Gamma) in DSS dispc
drm/omapdrm: Implement gamma_lut atomic crtc properties
drivers/gpu/drm/drm_crtc.c| 45
drivers/gpu/drm/drm_crtc_helper.c | 33 ---
drivers/gpu/drm/i915/intel_color.c| 3 +-
drivers/gpu/drm/omapdrm/dss/dispc.c | 374 --
drivers/gpu/drm/omapdrm/dss/dispc.h | 5 +
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 -
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 3 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 5 +
drivers/gpu/drm/omapdrm/omap_crtc.c | 28 +++
include/drm/drm_crtc.h| 5 +-
include/drm/drm_crtc_helper.h | 3 -
11 files changed, 447 insertions(+), 60 deletions(-)
--
1.9.1
[PATCH 03/14] drm: imx: ipuv3 plane: Check different types of plane separately
On Tue, May 24, 2016 at 10:20 PM, Philipp Zabel
wrote:
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> The IPUv3 primary plane doesn't support partial off screen.
>> So, this patch separates plane check logics for primary plane and overlay
>> plane and adds more limitations on the primary plane.
>>
>> Signed-off-by: Liu Ying
>> ---
>> drivers/gpu/drm/imx/ipuv3-plane.c | 72
>> ++-
>> 1 file changed, 41 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
>> b/drivers/gpu/drm/imx/ipuv3-plane.c
>> index e6ec8eb..8f91b2e 100644
>> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
>> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
>> @@ -190,44 +190,54 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
>> struct drm_crtc *crtc,
>> uint32_t src_x, uint32_t src_y,
>> uint32_t src_w, uint32_t src_h, bool interlaced)
>> {
>> - struct device *dev = ipu_plane->base.dev->dev;
>> + struct drm_plane plane = ipu_plane->base;
>
> Why make a copy of the drm_plane here?
Will remove that copy.
Regards,
Liu Ying
>
>> + struct device *dev = plane.dev->dev;
>> int ret;
>>
>> /* no scaling */
>> if (src_w != crtc_w || src_h != crtc_h)
>> return -EINVAL;
>>
>> - /* clip to crtc bounds */
>> - if (crtc_x < 0) {
>> - if (-crtc_x > crtc_w)
>> + if (plane.type == DRM_PLANE_TYPE_PRIMARY) {
>> + /* full plane doesn't support partial off screen */
>> + if (crtc_x || crtc_y || crtc_w != mode->hdisplay ||
>> + crtc_h != mode->vdisplay)
>
> As long as the requested plane is large enough to cover the whole base
> plane, we can fix the crtc_x/y/w/h up by clipping to the base plane
> boundaries. There is no need to return -EINVAL here as long as the IDMAC
> is capable to start reading at src_x/y = -crtc_x/y.
>
> regards
> Philipp
>
[PATCH v4 7/7] drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()
On 05/26/16 11:08, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 11:43:30PM +0300, Jyri Sarha wrote:
>> Remove obsolete drm_helper_crtc_enable_color_mgmt(). The function is
>> replaced by drm_crtc_enable_color_mgmt().
>>
>> Signed-off-by: Jyri Sarha
>
> Ah, here it is. Tbh this is patch splitting too far, since when you move a
> function it's much better to have the removal and addition in the same
> patch. If you split it like this then it's much harder to review.
>
> So please merge this with the addition patch + the patch to update i915.
> We can handle the resulting conflicts (if there are any) and
> cross-maintainer depencies.
> -Daniel
Ok, I'll do that and move the omapdrm patches after the
color_mgmt-patch, and squash omapdrm-patch #5 to patch #3.
BR,
Jyri
>
>> ---
>> drivers/gpu/drm/drm_crtc_helper.c | 33 -
>> include/drm/drm_crtc_helper.h | 3 ---
>> 2 files changed, 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
>> b/drivers/gpu/drm/drm_crtc_helper.c
>> index a6e4243..bf10d70 100644
>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>> @@ -1121,36 +1121,3 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc
>> *crtc, int x, int y,
>> return drm_plane_helper_commit(plane, plane_state, old_fb);
>> }
>> EXPORT_SYMBOL(drm_helper_crtc_mode_set_base);
>> -
>> -/**
>> - * drm_helper_crtc_enable_color_mgmt - enable color management properties
>> - * @crtc: DRM CRTC
>> - * @degamma_lut_size: the size of the degamma lut (before CSC)
>> - * @gamma_lut_size: the size of the gamma lut (after CSC)
>> - *
>> - * This function lets the driver enable the color correction properties on a
>> - * CRTC. This includes 3 degamma, csc and gamma properties that userspace
>> can
>> - * set and 2 size properties to inform the userspace of the lut sizes.
>> - */
>> -void drm_helper_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> - int degamma_lut_size,
>> - int gamma_lut_size)
>> -{
>> -struct drm_device *dev = crtc->dev;
>> -struct drm_mode_config *config = &dev->mode_config;
>> -
>> -drm_object_attach_property(&crtc->base,
>> - config->degamma_lut_property, 0);
>> -drm_object_attach_property(&crtc->base,
>> - config->ctm_property, 0);
>> -drm_object_attach_property(&crtc->base,
>> - config->gamma_lut_property, 0);
>> -
>> -drm_object_attach_property(&crtc->base,
>> - config->degamma_lut_size_property,
>> - degamma_lut_size);
>> -drm_object_attach_property(&crtc->base,
>> - config->gamma_lut_size_property,
>> - gamma_lut_size);
>> -}
>> -EXPORT_SYMBOL(drm_helper_crtc_enable_color_mgmt);
>> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
>> index 97fa894..4b37afa 100644
>> --- a/include/drm/drm_crtc_helper.h
>> +++ b/include/drm/drm_crtc_helper.h
>> @@ -48,9 +48,6 @@ extern bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>> struct drm_display_mode *mode,
>> int x, int y,
>> struct drm_framebuffer *old_fb);
>> -extern void drm_helper_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> - int degamma_lut_size,
>> - int gamma_lut_size);
>> extern bool drm_helper_crtc_in_use(struct drm_crtc *crtc);
>> extern bool drm_helper_encoder_in_use(struct drm_encoder *encoder);
>>
>> --
>> 1.9.1
>>
>
fsl-dcu not works on latest "drm-next"
On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
> Hi Mark,
>
> > You've not specifically described the problem here - what are the
> > endiannesses of both the CPU and the device you're talking to? What
> > specifically is the endianess problem you are seeing, what are you seeing
> > and what do you expect to see?
>
> The CPU is little endian and the device DCU is big endian, specified
> big-endian in DTS,
>
> And here is my DTS and regmap_config,
>
> Specified "big-endian" in DTS,
>
> dcu: dcu at 2ce {
> compatible = "fsl,ls1021a-dcu";
> reg = <0x0 0x2ce 0x0 0x1>;
> interrupts = ;
> clocks = <&platform_clk 0>;
> clock-names = "dcu";
> big-endian;
> status = "disabled";
> };
>
> I can't tell the difference of "reg_format_endian" and " val_format_endian
> ", so I had tried four conditions. And all failed.
>
> static const struct regmap_config fsl_dcu_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> .cache_type = REGCACHE_RBTREE,
This needs to be a flat cache. See
https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html or
https://lkml.org/lkml/2016/3/24/281
max_register also needs an appropriate value.
> // .reg_format_endian = REGMAP_ENDIAN_BIG, // .val_format_endian =
> REGMAP_ENDIAN_BIG,
>
> .volatile_reg = fsl_dcu_drm_is_volatile_reg, };
>
>
> I expect that regmap write as big endian, and I am seeing is regmap write as
> little endian.
Check your actual regmap reg_write function.
Best regards,
Alexander
fsl-dcu not works on latest "drm-next"
On Thursday 26 May 2016 08:18:30, Meng Yi wrote:
> Hi Alexander,
>
> > From your backtrace I guess wait_event_timeout is called in some atomic
> > context (might_sleep(); is called inside wait_event_timeout). This has
> > nothing to do with regmap.
>
> Here is my view of point:
> Since IRQ setup codes using regmap, and which is not setup properly, so
> wait_event_timeout.
> > The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> > ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> > commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> > 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> > 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> > could successfully probe DCU.
>
> Thanks for your information.
> DCU was able to be probed without those patches, and DCU still not works
> with those patches.
Yes, sure. DCU was probed fine before
922a9f936e40001f9b921379aab90047d5990923. But this introduced a regression for
DCU and also DSPI on LS1021A which got fixed by the other 3 named commits.
I didn't try to use DCU for a while, maybe there is another regression.
Please try reverting 2ed94f6fde066fb37bc3553b786edb805561699e
If that helps the device tree probing does not work in regmap_get_val_endian
Best regards,
Alexander
[PATCH 05/14] drm/crtc_helper: Disable and reenable primary plane in drm_helper_crtc_mode_set
On Wed, May 25, 2016 at 6:30 PM, Daniel Vetter wrote: > On Wed, May 25, 2016 at 05:37:41PM +0800, Ying Liu wrote: >> On Tue, May 24, 2016 at 6:57 PM, Daniel Vetter wrote: >> > On Tue, May 24, 2016 at 06:10:44PM +0800, Liu Ying wrote: >> >> Since CRTC has already been disabled in crtc_funcs->prepare(), it doesn't >> >> hurt >> >> to disable the primary plane in drm_helper_crtc_mode_set() before >> >> enabling it >> >> in drm_helper_crtc_mode_set_base(). This makes those who reject active >> >> plane >> >> update in plane_funcs->atomic_check() happy. >> > >> > How/where exactly do you blow up? >> >> >> >> Signed-off-by: Liu Ying >> >> --- >> >> drivers/gpu/drm/drm_crtc_helper.c | 9 + >> >> 1 file changed, 9 insertions(+) >> >> >> >> diff --git a/drivers/gpu/drm/drm_crtc_helper.c >> >> b/drivers/gpu/drm/drm_crtc_helper.c >> >> index 79555d2..7fabcd7 100644 >> >> --- a/drivers/gpu/drm/drm_crtc_helper.c >> >> +++ b/drivers/gpu/drm/drm_crtc_helper.c >> >> @@ -1013,6 +1013,15 @@ int drm_helper_crtc_mode_set(struct drm_crtc >> >> *crtc, struct drm_display_mode *mod >> >> goto out; >> >> } >> >> >> >> + /* >> >> + * It doesn't hurt to disable primary plane here since crtc is off >> >> + * and we'll enable it again in drm_helper_crtc_mode_set_base() >> >> + * below soon. >> >> + */ >> >> + ret = drm_plane_helper_disable(crtc->primary); >> > >> > You can't call this helper from crtc helpers. drm_plane_helper_disable >> > assumes that a) you've already extracted universal plane support for the >> > primary plane by registering a proper drm_plane for it b) that you're >> > driver is at least partially using atomic hooks already. >> > >> > Both assumptions are wrong for all current users of this function. >> > drm_helper_crtc_mode_set() is purely a legacy helper for legecy drivers. >> >> Isn't the function a transitional helper, just as the kdoc claims? >> It looks all current users are sort of atomic users already. > > drm_helper_crtc_mode_set is exclusively used by legacy drivers. > drm_plane_helper_disable can be used for transitioning to atomic. Again, please take a look at the kdoc of drm_helper_crtc_mode_set. It reads 'Besides the atomic plane helper functions for the primary plane the driver must also provide the ->mode_set_nofb callback to set up the CRTC. This is a transitional helper useful for converting drivers to the atomic interfaces.' > > Calling the latter from the former means you break every non-transition > legacy driver. drm_helper_crtc_mode_set calls drm_helper_crtc_mode_set_base. Both drm_helper_crtc_mode_set_base and drm_plane_helper_disable call drm_plane_helper_commit, so they are somewhat counterparts, that is to say, drm_helper_crtc_mode_set may call drm_plane_helper_disable technically. Regards, Liu Ying > -Daniel > >> >> Regards, >> Liu Ying >> >> > -Daniel >> > >> >> + if (ret) >> >> + goto out; >> >> + >> >> swap(crtc->state, crtc_state); >> >> >> >> crtc_funcs->mode_set_nofb(crtc); >> >> -- >> >> 2.7.4 >> >> >> >> ___ >> >> dri-devel mailing list >> >> dri-devel at lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > >> > -- >> > Daniel Vetter >> > Software Engineer, Intel Corporation >> > http://blog.ffwll.ch > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[PATCH 13/20] drm/bridge: Add RGB to VGA bridge support
t(struct drm_connector *connector, bool force)
> > +{
> > + return connector_status_connected;
>
> Shouldn't that be connector_status_unknown if you have no information about
> the connection status ?
Probably :)
What are the side effects from such a change? Does it change anything
related to how the fbdev emulation and how the rest of the display
stack detects and enables the outputs whose status are unknown?
> Would it make sense to add an optional GPIO-based connection detection to
> this
> driver ?
I asked for it in our prototypes, and apparently, doing VGA cable
detection is really non-trivial, so I don't really expect it to be
found in a lot of designs.
I looked at three different designs done by different vendors, and
none of them have it, so I don't really expect anyone to have it, nor
do I have any hardware to test the code with. However, if there's an
i2c bus, we can always try to probe for the edid, and see if we have
an error. If there's none, then we know something is connected. If
there's an error, we can return connector_status_unknown.
On a set of three samples, only one has that i2c bus, so it might be
just a marginal improvement, but still.
> > +}
> > +
> > +static void
> > +dumb_vga_connector_destroy(struct drm_connector *connector)
> > +{
> > + drm_connector_cleanup(connector);
> > +}
> > +
> > +static struct drm_connector_funcs dumb_vga_con_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
> > + .detect = dumb_vga_connector_detect,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .destroy= dumb_vga_connector_destroy,
> > + .reset = drm_atomic_helper_connector_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > +};
> > +
> > +static int dumb_vga_attach(struct drm_bridge *bridge)
> > +{
> > + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> > + int ret;
> > +
> > + if (!bridge->encoder) {
> > + DRM_ERROR("Missing encoder\n");
> > + return -ENODEV;
> > + }
> > +
> > + drm_connector_helper_add(&vga->connector,
> > +&dumb_vga_con_helper_funcs);
> > + ret = drm_connector_init(bridge->dev, &vga->connector,
> > +&dumb_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
> > + if (ret) {
> > + DRM_ERROR("Failed to initialize connector\n");
> > + return ret;
> > + }
> > +
> > + drm_mode_connector_attach_encoder(&vga->connector,
> > + bridge->encoder);
> > +
> > + return 0;
> > +}
> > +
> > +static void dumb_vga_nop(struct drm_bridge *bridge) {};
> > +
> > +static struct drm_bridge_funcs dumb_vga_bridge_funcs = {
> > + .attach = dumb_vga_attach,
> > + .enable = dumb_vga_nop,
> > + .disable= dumb_vga_nop,
> > + .pre_enable = dumb_vga_nop,
> > + .post_disable = dumb_vga_nop,
> > +};
> > +
> > +static int dumb_vga_probe(struct platform_device *pdev)
> > +{
> > + struct dumb_vga *vga;
> > + struct device_node *ddc;
> > +
> > + vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
> > + if (!vga)
> > + return -ENOMEM;
> > + platform_set_drvdata(pdev, vga);
> > +
> > + ddc = of_parse_phandle(pdev->dev.of_node, "ddc-i2c-bus", 0);
> > + if (ddc) {
> > + vga->ddc = of_find_i2c_adapter_by_node(ddc);
>
> You're leaking the reference to the I2C adapter.
>
> Also, shouldn't you use of_get_i2c_adapter_by_node() ? Otherwise you won't
> take a reference to the adapter module.
Indeed, I'll fix it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/985ae173/attachment.sig>
[PATCH] drm: sti: fix clocking issues in crtc
fix and simplify clock management in crtc to avoid unbalanced
call to clk_prepare_enable and clk_disable_unprepare functions
remove unused functions
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_crtc.c | 57 +-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 505620c..5261b00 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -30,15 +30,6 @@ static void sti_crtc_enable(struct drm_crtc *crtc)
mixer->status = STI_MIXER_READY;
- /* Prepare and enable the compo IP clock */
- if (mixer->id == STI_MIXER_MAIN) {
- if (clk_prepare_enable(compo->clk_compo_main))
- DRM_INFO("Failed to prepare/enable compo_main clk\n");
- } else {
- if (clk_prepare_enable(compo->clk_compo_aux))
- DRM_INFO("Failed to prepare/enable compo_aux clk\n");
- }
-
drm_crtc_vblank_on(crtc);
}
@@ -66,9 +57,8 @@ sti_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode)
struct sti_mixer *mixer = to_sti_mixer(crtc);
struct device *dev = mixer->dev;
struct sti_compositor *compo = dev_get_drvdata(dev);
- struct clk *clk;
+ struct clk *compo_clk, *pix_clk;
int rate = mode->clock * 1000;
- int res;
DRM_DEBUG_KMS("CRTC:%d (%s) mode:%d (%s)\n",
crtc->base.id, sti_mixer_to_str(mixer),
@@ -83,32 +73,46 @@ sti_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode)
mode->vsync_start, mode->vsync_end,
mode->vtotal, mode->type, mode->flags);
- /* Set rate and prepare/enable pixel clock */
- if (mixer->id == STI_MIXER_MAIN)
- clk = compo->clk_pix_main;
- else
- clk = compo->clk_pix_aux;
+ if (mixer->id == STI_MIXER_MAIN) {
+ compo_clk = compo->clk_compo_main;
+ pix_clk = compo->clk_pix_main;
+ } else {
+ compo_clk = compo->clk_compo_aux;
+ pix_clk = compo->clk_pix_aux;
+ }
- res = clk_set_rate(clk, rate);
- if (res < 0) {
+ /* Prepare and enable the compo IP clock */
+ if (clk_prepare_enable(compo_clk)) {
+ DRM_INFO("Failed to prepare/enable compositor clk\n");
+ goto compo_error;
+ }
+
+ /* Set rate and prepare/enable pixel clock */
+ if (clk_set_rate(pix_clk, rate) < 0) {
DRM_ERROR("Cannot set rate (%dHz) for pix clk\n", rate);
- return -EINVAL;
+ goto pix_error;
}
- if (clk_prepare_enable(clk)) {
+ if (clk_prepare_enable(pix_clk)) {
DRM_ERROR("Failed to prepare/enable pix clk\n");
- return -EINVAL;
+ goto pix_error;
}
sti_vtg_set_config(mixer->id == STI_MIXER_MAIN ?
compo->vtg_main : compo->vtg_aux, &crtc->mode);
- res = sti_mixer_active_video_area(mixer, &crtc->mode);
- if (res) {
+ if (sti_mixer_active_video_area(mixer, &crtc->mode)) {
DRM_ERROR("Can't set active video area\n");
- return -EINVAL;
+ goto mixer_error;
}
- return res;
+ return 0;
+
+mixer_error:
+ clk_disable_unprepare(pix_clk);
+pix_error:
+ clk_disable_unprepare(compo_clk);
+compo_error:
+ return -EINVAL;
}
static void sti_crtc_disable(struct drm_crtc *crtc)
@@ -139,7 +143,6 @@ static void sti_crtc_disable(struct drm_crtc *crtc)
static void
sti_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
- sti_crtc_enable(crtc);
sti_crtc_mode_set(crtc, &crtc->state->adjusted_mode);
}
@@ -231,9 +234,7 @@ static const struct drm_crtc_helper_funcs
sti_crtc_helper_funcs = {
.enable = sti_crtc_enable,
.disable = sti_crtc_disabling,
.mode_fixup = sti_crtc_mode_fixup,
- .mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = sti_crtc_mode_set_nofb,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.atomic_begin = sti_crtc_atomic_begin,
.atomic_flush = sti_crtc_atomic_flush,
};
--
1.9.1
[PATCH] drm: Store the plane's index
Currently the plane's index is determined by walking the list of all
planes in the mode and finding the position of that plane in the list. A
linear walk, especially a linear walk within a linear walk as frequently
conceived by i915.ko [O(N^2)] quickly comes to dominate profiles.
The plane's index is constant for as long as no earlier planes are
removed from the list. For most drivers, planes are static, determined
at boot and then untouched until shutdown. Storing the index upon
construction and then only walking the tail upon removal should
be a major improvement for all.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 38 +-
include/drm/drm_crtc.h | 6 +-
2 files changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3a0384cce4a2..00ee01126b6f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1302,7 +1302,7 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
plane->type = type;
list_add_tail(&plane->head, &config->plane_list);
- config->num_total_plane++;
+ plane->index = config->num_total_plane++;
if (plane->type == DRM_PLANE_TYPE_OVERLAY)
config->num_overlay_plane++;
@@ -1369,6 +1369,7 @@ EXPORT_SYMBOL(drm_plane_init);
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane->dev;
+ struct drm_plane *other;
drm_modeset_lock_all(dev);
kfree(plane->format_types);
@@ -1376,6 +1377,10 @@ void drm_plane_cleanup(struct drm_plane *plane)
BUG_ON(list_empty(&plane->head));
+ other = list_next_entry(plane, head);
+ list_for_each_entry_from(other, &dev->mode_config.plane_list, head)
+ other->index--;
+
list_del(&plane->head);
dev->mode_config.num_total_plane--;
if (plane->type == DRM_PLANE_TYPE_OVERLAY)
@@ -1393,29 +1398,6 @@ void drm_plane_cleanup(struct drm_plane *plane)
EXPORT_SYMBOL(drm_plane_cleanup);
/**
- * drm_plane_index - find the index of a registered plane
- * @plane: plane to find index for
- *
- * Given a registered plane, return the index of that CRTC within a DRM
- * device's list of planes.
- */
-unsigned int drm_plane_index(struct drm_plane *plane)
-{
- unsigned int index = 0;
- struct drm_plane *tmp;
-
- drm_for_each_plane(tmp, plane->dev) {
- if (tmp == plane)
- return index;
-
- index++;
- }
-
- BUG();
-}
-EXPORT_SYMBOL(drm_plane_index);
-
-/**
* drm_plane_from_index - find the registered plane at an index
* @dev: DRM device
* @idx: index of registered plane to find for
@@ -1427,13 +1409,11 @@ struct drm_plane *
drm_plane_from_index(struct drm_device *dev, int idx)
{
struct drm_plane *plane;
- unsigned int i = 0;
- drm_for_each_plane(plane, dev) {
- if (i == idx)
+ drm_for_each_plane(plane, dev)
+ if (idx == plane->index)
return plane;
- i++;
- }
+
return NULL;
}
EXPORT_SYMBOL(drm_plane_from_index);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 9771428e1ba8..eda3b1b3d3b4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1543,6 +1543,7 @@ struct drm_plane {
struct drm_object_properties properties;
enum drm_plane_type type;
+ unsigned index;
const struct drm_plane_helper_funcs *helper_private;
@@ -2316,7 +2317,10 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, unsigned int format_count,
bool is_primary);
extern void drm_plane_cleanup(struct drm_plane *plane);
-extern unsigned int drm_plane_index(struct drm_plane *plane);
+static inline unsigned int drm_plane_index(struct drm_plane *plane)
+{
+ return plane->index;
+}
extern struct drm_plane * drm_plane_from_index(struct drm_device *dev, int
idx);
extern void drm_plane_force_disable(struct drm_plane *plane);
extern int drm_plane_check_pixel_format(const struct drm_plane *plane,
--
2.8.1
[PATCH 13/20] drm/bridge: Add RGB to VGA bridge support
On Thu, May 26, 2016 at 10:53:30AM +0200, Maxime Ripard wrote: > Hi Laurent, > > On Mon, May 16, 2016 at 04:24:15PM +0300, Laurent Pinchart wrote: > > Hi Maxime, > > > > Thank you for the patch. > > > > On Monday 16 May 2016 14:47:13 Maxime Ripard wrote: > > > +fallback: > > > + /* > > > + * In case we cannot retrieve the EDIDs (broken or missing i2c > > > + * bus), fallback on the XGA standards > > > + */ > > > + ret = drm_add_modes_noedid(connector, 1920, 1200); > > > > The DRM core adds modes up to 1024x768 in > > drm_helper_probe_single_connector_modes(). I wonder if it really makes > > sense > > to override that in drivers, compared to increasing the maximum resolution > > in > > the core. What we can reasonable expect from a VGA monitor doesn't really > > depend on which display engine it is connected to. > > Actually, I would expect it to come from the connectors. Nowadays, the > core add modes that might not even be relevant at all for a given > connector. Take TV as an example, there's not a single TV output that > can reach 1024x768, but actually rely on very different resolutions. There is the requirement to support 640x480 almost universally. > > Would it make sense to add an optional GPIO-based connection detection to > > this > > driver ? > > I asked for it in our prototypes, and apparently, doing VGA cable > detection is really non-trivial, so I don't really expect it to be > found in a lot of designs. ... and prone to problems. Intel designs try to measure the termination resistance to detect whether something is connected (they pulse the RGB signals and measure the current.) This mostly works fine, except if you have some KVM boxes which can make this very unreliable. I ended up replacing the bipolar transistors switching the RGB signals in my KVM switch with FETs because of this problem. -- 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.
[PATCH 0/8] scheduler code cleanup
On Wed, May 25, 2016 at 05:04:14PM -0400, Alex Deucher wrote: > Just some general cleanup in the GPU scheduler. > > Christian König (8): Since when has Christian forgot how git send-email works? ;-) Cheers, Daniel > drm/amdgpu: fix coding style in the scheduler v2 > drm/amdgpu: remove begin_job/finish_job > drm/amdgpu: remove duplicated timeout callback > drm/amdgpu: fix coding style in amdgpu_job_free > drm/amdgpu: remove use_shed hack in job cleanup > drm/amdgpu: properly abstract scheduler timeout handling > drm/amdgpu: move locking into the functions who need it > drm/amdgpu: fix and cleanup job destruction > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 - > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 49 +++ > drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 89 > ++- > drivers/gpu/drm/amd/scheduler/gpu_scheduler.h | 42 - > drivers/gpu/drm/amd/scheduler/sched_fence.c | 19 ++ > 6 files changed, 86 insertions(+), 119 deletions(-) > > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v4 7/7] drm: Remove obsolete drm_helper_crtc_enable_color_mgmt()
On Wed, May 25, 2016 at 11:43:30PM +0300, Jyri Sarha wrote:
> Remove obsolete drm_helper_crtc_enable_color_mgmt(). The function is
> replaced by drm_crtc_enable_color_mgmt().
>
> Signed-off-by: Jyri Sarha
Ah, here it is. Tbh this is patch splitting too far, since when you move a
function it's much better to have the removal and addition in the same
patch. If you split it like this then it's much harder to review.
So please merge this with the addition patch + the patch to update i915.
We can handle the resulting conflicts (if there are any) and
cross-maintainer depencies.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 33 -
> include/drm/drm_crtc_helper.h | 3 ---
> 2 files changed, 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a6e4243..bf10d70 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -1121,36 +1121,3 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc
> *crtc, int x, int y,
> return drm_plane_helper_commit(plane, plane_state, old_fb);
> }
> EXPORT_SYMBOL(drm_helper_crtc_mode_set_base);
> -
> -/**
> - * drm_helper_crtc_enable_color_mgmt - enable color management properties
> - * @crtc: DRM CRTC
> - * @degamma_lut_size: the size of the degamma lut (before CSC)
> - * @gamma_lut_size: the size of the gamma lut (after CSC)
> - *
> - * This function lets the driver enable the color correction properties on a
> - * CRTC. This includes 3 degamma, csc and gamma properties that userspace can
> - * set and 2 size properties to inform the userspace of the lut sizes.
> - */
> -void drm_helper_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> -int degamma_lut_size,
> -int gamma_lut_size)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_mode_config *config = &dev->mode_config;
> -
> - drm_object_attach_property(&crtc->base,
> -config->degamma_lut_property, 0);
> - drm_object_attach_property(&crtc->base,
> -config->ctm_property, 0);
> - drm_object_attach_property(&crtc->base,
> -config->gamma_lut_property, 0);
> -
> - drm_object_attach_property(&crtc->base,
> -config->degamma_lut_size_property,
> -degamma_lut_size);
> - drm_object_attach_property(&crtc->base,
> -config->gamma_lut_size_property,
> -gamma_lut_size);
> -}
> -EXPORT_SYMBOL(drm_helper_crtc_enable_color_mgmt);
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 97fa894..4b37afa 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -48,9 +48,6 @@ extern bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>struct drm_display_mode *mode,
>int x, int y,
>struct drm_framebuffer *old_fb);
> -extern void drm_helper_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> - int degamma_lut_size,
> - int gamma_lut_size);
> extern bool drm_helper_crtc_in_use(struct drm_crtc *crtc);
> extern bool drm_helper_encoder_in_use(struct drm_encoder *encoder);
>
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH libdrm] radeon: use SAMPLE_SPLIT=2 for better MSAA perf on EG/CM
On Thu, May 26, 2016 at 9:38 AM, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 5ec9745..1424660 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -957,8 +957,10 @@ static int eg_surface_best(struct radeon_surface_manager
> *surf_man,
> }
> surf->stencil_tile_split = 64;
> } else {
> -/* tile split must be >= 256 for colorbuffer surfaces */
> -surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
> +/* tile split must be >= 256 for colorbuffer surfaces,
> + * SAMPLE_SPLIT = tile_split / (bpe * 64), the optimal value is 2
> + */
> +surf->tile_split = MAX2(2 * surf->bpe * 64, 256);
> if (surf->tile_split > 4096)
> surf->tile_split = 4096;
> }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] drm: Add drm_crtc_enable_color_mgmt()
On Wed, May 25, 2016 at 10:19:50PM +0100, Emil Velikov wrote: > On 25 May 2016 at 22:05, Emil Velikov wrote: > > On 25 May 2016 at 21:43, Jyri Sarha wrote: > >> Add drm_crtc_enable_color_mgmt() to. The new function makes the old > >> drm_helper_crtc_enable_color_mgmt() obsolete. The new function is more > >> flexible. It allows driver to enable only the feature it has without > >> forcing to enable all three color management features: gegamma lut, csc > >> matrix (ctm), and gamma lut. > >> > > Why don't we just update the existing one ? In one step (patch) or two > > - a) don't register property if respective _lut_size is zero b) bring > > in has_ctm. > > > Ouch I missed that the goal here is to move the function out of > drm_crtc_helper.c. Sorry about that. The goal still was to move it, and update the existing callers. Adding a new without removing the old one is not what I suggested really ;-) -Daniel > > Perhaps the commit message can be reworded a bit - something like the > following comes to mind. > > "Introduce drm_crtc_enable_color_mgmt() function which supersedes the > crtc_helper one (xxx: add name). The latter always creates all > properties (xxx: list props) and is not really a helper. > The new version allows explicit control of the properties created as > required by some hardware/drivers (xxx: name driver)." > > Feel free to reuse and/tweak. > > Thanks > Emil > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
DRM DMA Engine
On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: > Hi all, > > Currently I am trying to develop a DRM driver that will use > Xilinx VDMA to transfer video data to a HDMI TX Phy and I am > facing a difficulty regarding the understanding of the DRM DMA > Engine. I looked at several sources and at the DRM core source > but the flow of creating and interfacing with the DMA controller > is still not clear to me. > > At DRI web page the X server is mentioned. Does it mean that the > channel creation and handling is done by the X server? If so, > what is the DRM driver responsible to do then and what exactly > does the DRM core do? As I am using Xilinx VDMA do you foresee > any special implementation details? > > Just for reference here is the description of the Xilinx VDMA: > "The Advanced eXtensible Interface Video Direct Memory Access > (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core > providing high-bandwidth direct memory access between memory and > AXI4-Stream video type target peripherals including peripherals > which support AXI4-Stream Video Protocol." The driver is > available at "drivers/dma/xilinx/xilinx_vdma.c". > > Another important point: I am using PCI Express connected to a > FPGA which has all the necessary components (Xilinx VDMA, I2S, > ...) and the HDMI TX Phy. > > Looking forward to you help. If your dma engine is just for HDMI display, forget all the stuff you find about DRI and X server on the various wikis. That's for opengl rendering. The only thing you need is a kernel-modesetting driver, and nowadays those are written using the atomic modeset framework. There's plenty of introductory talks and stuff all over the web (I suggest the latest version of Laurent Pinchart's talk as a good starting point). -Daniel > > Best regards, > Jose Miguel Abreu > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 05/14] drm/crtc_helper: Disable and reenable primary plane in drm_helper_crtc_mode_set
On Tue, May 24, 2016 at 06:10:44PM +0800, Liu Ying wrote: > Since CRTC has already been disabled in crtc_funcs->prepare(), it doesn't hurt > to disable the primary plane in drm_helper_crtc_mode_set() before enabling it > in drm_helper_crtc_mode_set_base(). This makes those who reject active plane > update in plane_funcs->atomic_check() happy. > > Signed-off-by: Liu Ying > --- > drivers/gpu/drm/drm_crtc_helper.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc_helper.c > b/drivers/gpu/drm/drm_crtc_helper.c > index 79555d2..7fabcd7 100644 > --- a/drivers/gpu/drm/drm_crtc_helper.c > +++ b/drivers/gpu/drm/drm_crtc_helper.c > @@ -1013,6 +1013,15 @@ int drm_helper_crtc_mode_set(struct drm_crtc *crtc, > struct drm_display_mode *mod > goto out; > } > > + /* > + * It doesn't hurt to disable primary plane here since crtc is off > + * and we'll enable it again in drm_helper_crtc_mode_set_base() > + * below soon. > + */ > + ret = drm_plane_helper_disable(crtc->primary); > + if (ret) > + goto out; > + Ok, so there's no problem with mixing up legacy and transitional helpers here. It's still not how it's supposed to work though. All the helpers (legacy, transitional & atomic) assume that when the helpers call into crtc->disable hooks, the driver will also disable all the scanout engines. The helpers will _not_ do that for you, it's the driver duties. For atomic we have a helper function which you can call at the right place, drm_atomic_helper_disable_planes_on_crtc(). Unfortunately it looks like no one ever used it, so probably a bunch of bugs in drivers because of this. Explicitly disabling the plane when the crtc is shut down might confused/break drivers which get this right, hence why we can't have this in the helper libraries. In short: You need to fix this in your driver, by manually disabling the plane at a suitable place first. Most likely that's in the crtc->prepare hook (since you're still transitioning). -Daniel > swap(crtc->state, crtc_state); > > crtc_funcs->mode_set_nofb(crtc); > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 05/14] drm/crtc_helper: Disable and reenable primary plane in drm_helper_crtc_mode_set
On Thu, May 26, 2016 at 11:02:55AM +0800, Ying Liu wrote: > On Wed, May 25, 2016 at 6:30 PM, Daniel Vetter wrote: > > On Wed, May 25, 2016 at 05:37:41PM +0800, Ying Liu wrote: > >> On Tue, May 24, 2016 at 6:57 PM, Daniel Vetter wrote: > >> > On Tue, May 24, 2016 at 06:10:44PM +0800, Liu Ying wrote: > >> >> Since CRTC has already been disabled in crtc_funcs->prepare(), it > >> >> doesn't hurt > >> >> to disable the primary plane in drm_helper_crtc_mode_set() before > >> >> enabling it > >> >> in drm_helper_crtc_mode_set_base(). This makes those who reject active > >> >> plane > >> >> update in plane_funcs->atomic_check() happy. > >> > > >> > How/where exactly do you blow up? > >> >> > >> >> Signed-off-by: Liu Ying > >> >> --- > >> >> drivers/gpu/drm/drm_crtc_helper.c | 9 + > >> >> 1 file changed, 9 insertions(+) > >> >> > >> >> diff --git a/drivers/gpu/drm/drm_crtc_helper.c > >> >> b/drivers/gpu/drm/drm_crtc_helper.c > >> >> index 79555d2..7fabcd7 100644 > >> >> --- a/drivers/gpu/drm/drm_crtc_helper.c > >> >> +++ b/drivers/gpu/drm/drm_crtc_helper.c > >> >> @@ -1013,6 +1013,15 @@ int drm_helper_crtc_mode_set(struct drm_crtc > >> >> *crtc, struct drm_display_mode *mod > >> >> goto out; > >> >> } > >> >> > >> >> + /* > >> >> + * It doesn't hurt to disable primary plane here since crtc is off > >> >> + * and we'll enable it again in drm_helper_crtc_mode_set_base() > >> >> + * below soon. > >> >> + */ > >> >> + ret = drm_plane_helper_disable(crtc->primary); > >> > > >> > You can't call this helper from crtc helpers. drm_plane_helper_disable > >> > assumes that a) you've already extracted universal plane support for the > >> > primary plane by registering a proper drm_plane for it b) that you're > >> > driver is at least partially using atomic hooks already. > >> > > >> > Both assumptions are wrong for all current users of this function. > >> > drm_helper_crtc_mode_set() is purely a legacy helper for legecy drivers. > >> > >> Isn't the function a transitional helper, just as the kdoc claims? > >> It looks all current users are sort of atomic users already. > > > > drm_helper_crtc_mode_set is exclusively used by legacy drivers. > > drm_plane_helper_disable can be used for transitioning to atomic. > > Again, please take a look at the kdoc of drm_helper_crtc_mode_set. > It reads 'Besides the atomic plane helper functions for the primary > plane the driver must also provide the ->mode_set_nofb callback > to set up the CRTC. This is a transitional helper useful for converting > drivers to the atomic interfaces.' Oops, my apologies, I mixed it all up in my head. Sorry for all the mess, I'll start a new thread since this discussion here is a bit confusion now. -Daniel > > Calling the latter from the former means you break every non-transition > > legacy driver. > > drm_helper_crtc_mode_set calls drm_helper_crtc_mode_set_base. > Both drm_helper_crtc_mode_set_base and drm_plane_helper_disable > call drm_plane_helper_commit, so they are somewhat counterparts, > that is to say, drm_helper_crtc_mode_set may call > drm_plane_helper_disable technically. > > Regards, > Liu Ying > > > -Daniel > > > >> > >> Regards, > >> Liu Ying > >> > >> > -Daniel > >> > > >> >> + if (ret) > >> >> + goto out; > >> >> + > >> >> swap(crtc->state, crtc_state); > >> >> > >> >> crtc_funcs->mode_set_nofb(crtc); > >> >> -- > >> >> 2.7.4 > >> >> > >> >> ___ > >> >> dri-devel mailing list > >> >> dri-devel at lists.freedesktop.org > >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > > >> > -- > >> > Daniel Vetter > >> > Software Engineer, Intel Corporation > >> > http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH v4] drm/i915/ilk: Don't disable SSC source if it's in use
On Wed, May 25, 2016 at 02:11:02PM -0400, Lyude wrote:
> Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
>
> Unfortunately one of the sideaffects of having the refclk for a DPLL set
> to SSC is that as long as it's set to SSC, the GPU will prevent us from
> powering down any of the pipes or transcoders using it. A couple of
> BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
> configurations. This causes issues on the first modeset, since we don't
> expect SSC to be left on and as a result, can't successfully power down
> the pipes or the transcoders using it. Here's an example from this Dell
> OptiPlex 990:
>
> [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says
> disabled
> [drm:intel_modeset_init] 2 display pipes available.
> [drm:intel_update_cdclk] Current CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
> vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [drm:intel_crt_reset] crt adpa set to 0xf4
> [drm:intel_dp_init_connector] Adding DP connector on port C
> [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
> [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
> [drm:ironlake_init_pch_refclk] Disabling SSC entirely
> ⦠later we try committing the first modeset â¦
> [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for
> pipe A
> [drm:intel_dump_pipe_config] cpu_transcoder: A
> â¦
> [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0,
> fp0: 0x20e08, fp1: 0x30d07
> [drm:intel_dump_pipe_config] planes on this crtc
> [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
> [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
> [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0)
> 800x600
> [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled,
> scaler_id = 0
> [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled,
> scaler_id = 0
> [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
> [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
> [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
> [drm:intel_disable_pipe] disabling pipe A
> [ cut here ]
> WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146
> intel_disable_pipe+0x297/0x2d0 [i915]
> pipe_off wait timed out
> â¦
> ---[ end trace 94fc8aa03ae139e8 ]---
> [drm:intel_dp_link_down]
> [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
>
> Later modesets succeed since they reset the DPLL's configuration anyway,
> but this is enough to get stuck with a big fat warning in dmesg.
>
> A better solution would be to add refcounts for the SSC source, but for
> now leaving the source clock on should suffice.
>
> Changes since v3:
> - Move temp variable into loop
> - Move checks for using_ssc_source to after we've figured out has_ck505
> - Add using_ssc_source to debug output
> Changes since v2:
> - Fix debug output for when we disable the CPU source
> Changes since v1:
> - Leave the SSC source clock on instead of just shutting it off on all
>of the DPLL configurations.
>
> Cc: stable at vger.kernel.org
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Lyude
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 49
> ++--
> 1 file changed, 36 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d500e6f..471e3a8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct
> drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_encoder *encoder;
> + int i;
> u32 val, final;
> bool has_lvds = false;
> bool has_cpu_edp = false;
> bool has_panel = false;
> bool has_ck505 = false;
> bool can_ssc = false;
> + bool using_ssc_source = false;
>
> /* We need to take the global config into account */
> for_each_intel_encoder(dev, encoder) {
> @@ -8262,8 +8264,22 @@ static void ironlake_init_pch_refclk(struct drm_device
> *dev)
> can_ssc = true;
> }
>
> - DRM_DEBUG_KMS("has_panel %d has_lvds %d has_ck505 %d\n",
> - has_panel, has_lvds, has_ck505);
> + /* Check if any DPLLs are using the SSC source */
> + for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> + u32 temp = I915_READ(PCH_DPLL(i));
> +
> + if (!(temp & DPLL_VCO_ENABLE))
> + continue;
> +
> + if ((temp & PLL_REF_INPUT_MASK) ==
> + PLLB_REF
[PATCH] drm: expand cea861 mode timing table
On Wed, May 25, 2016 at 07:55:23PM +, Yang, Eric wrote:
> Hi Thierry Reding,
>
> enum hdmi_picture_aspect {
> > HDMI_PICTURE_ASPECT_NONE,
> > HDMI_PICTURE_ASPECT_4_3,
> > HDMI_PICTURE_ASPECT_16_9,
> > + HDMI_PICTURE_ASPECT_64_27,
> > + HDMI_PICTURE_ASPECT_256_135,
> > HDMI_PICTURE_ASPECT_RESERVED,
> > };
>
> These are defined since CEA861F defines them in section 4.1.
> However, it is not indicated in AVI InfoFrame definition for picture aspect
> ratio (M1,M0), and we should indicate (M1,M0) = (0,0) for "No Data" when
> sending VICs corresponding to these new aspect ratios.
>
> If (M1,M0) = (0,0) "No Data" is indicated, then If M=0 (M1=0, M0=0) and
> VIC=0, a Sink shall assume the Picture is formatted according to the
> Preferred Picture Aspect Ratio.
>
> The defition:
>
> Preferred Picture Aspect Ratio-In a Dual-Aspect Ratio DTV, the preferred
> aspect ratio of a given Video Format Timing (e.g., 720x480p) is the aspect
> ratio of the first such timing listed in the EDID data structure (see Section
> 4.1). This would be the Picture Aspect Ratio that would be displayed if a DTV
> were to receive a Video Format Timing with no accompanying Picture Aspect
> Ratio information (i.e., no AVI sent from Source).
>
> Alternatively, since our code does not actively use
> HDMI_PICTURE_ASPECT_64_27, HDMI_PICTURE_ASPECT_256_135, we can unify them as
> HDMI_PICTURE_ASPECT_NONE, and send (M1,M0) = (0,0) to avoid confusion.
There's already drm core patches to add all this stuff for the new aspect
ratios:
https://patchwork.freedesktop.org/series/4896/
Would be great if you can review them. Patch 5 of that series (for
i915.ko) needs to be polished a bit, but the other bits all look fine to
me at a quick glance.
Thanks, Daniel
>
>
>
> -Original Message-
> From: Thierry Reding
> Sent: Friday, May 13, 2016 11:28:39 AM
> To: Yang, Eric
> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org;
> tomi.valkeinen at ti.com; plagnioj at jcrosoft.com
> Subject: Re: [PATCH] drm: expand cea861 mode timing table
>
> On Thu, May 12, 2016 at 03:37:33PM -0400, Eric Yang wrote:
> [...]
> > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
> > e974420..edbb4fc 100644
> > --- a/include/linux/hdmi.h
> > +++ b/include/linux/hdmi.h
> > @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
> > HDMI_PICTURE_ASPECT_NONE,
> > HDMI_PICTURE_ASPECT_4_3,
> > HDMI_PICTURE_ASPECT_16_9,
> > + HDMI_PICTURE_ASPECT_64_27,
> > + HDMI_PICTURE_ASPECT_256_135,
> > HDMI_PICTURE_ASPECT_RESERVED,
> > };
>
> Where did you get these from? I'm asking because I sent this patch last year
> (or at least I wrote it and we discussed it on IRC, since I can't find an
> email archive link to it), and back at the time the picture aspect ratio was
> the big question mark. My recollection is that CEA-861-F introduces these new
> picture aspect ratios in the mode tables but never specifies their values. As
> a matter of fact, the AVI infoframe where these values are used only has
> space for 4 values (none, 4:3, 16:9 and reserved).
>
> Would you mind pointing me at the specification for these values?
>
> Thanks,
> Thierry
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/amd: add Kconfig dependency for ACP on DRM_AMDGPU
On 5/25/16 5:09 PM, Emil Velikov wrote: > Hi Jeff, > > I'm thinking out loud so here are a few suggestions/ideas. Please > don't take them too seriously although they do make sense from this > end. Hi Emil - I'm not at all involved in amdgpu development. This patch came from me fielding reports that the openSUSE Tumbleweed kernel had MFD_CORE=y as part of a version update. In the process of troubleshooting, I did see how the code was structured and there are some interesting choices in there. > On 24 May 2016 at 18:47, Jeff Mahoney wrote: >> The DRM_AMD_ACP option doesn't have any dependencies and selects >> MFD_CORE, which results in MFD_CORE=y. Since the code is only called >> from DRM_AMDGPU, it should depend on it. Adding the dependency results >> in MFD_CORE being selected as a module again if amdgpu is also a module. >> >> Signed-off-by: Jeff Mahoney >> --- >> drivers/gpu/drm/amd/acp/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/gpu/drm/amd/acp/Kconfig >> b/drivers/gpu/drm/amd/acp/Kconfig >> index ca77ec1..e503e3d 100644 >> --- a/drivers/gpu/drm/amd/acp/Kconfig >> +++ b/drivers/gpu/drm/amd/acp/Kconfig >> @@ -2,6 +2,7 @@ menu "ACP (Audio CoProcessor) Configuration" >> >> config DRM_AMD_ACP >> bool "Enable AMD Audio CoProcessor IP support" >> + depends on DRM_AMDGPU >> select MFD_CORE >> select PM_GENERIC_DOMAINS if PM >> help >> > Afaict ACP/Powerplay doesn't make sense on their own so here is an > alternative solution: > - create a Kconfig in drm/amd and move/consolidate amdgpu, powerplay, > acp in there. I have a patch to do this already. The bigger issue, though, is the weird hierarchy that may make sense for an external driver but is an outlier for in-kernel drivers. > amdkfd can be moved as well afaict. > - make DRM_AMD_ACP and DRM_AMD_POWERPLAY submenu items for > DRM_AMDGPU. AMDKFD on the other hand depends on RADEON || AMDGPU so it > should stay separate. > - crazy idea: add select and/or depends on SND_SOC_AMD_ACP. since one > is useless without the other. Or perhaps make the SOC entry should > select/depend on AMD_ACP ? > > And some future work (cleanups): > - fold the acp folder (or inline respective files) within amdgpu. Yes. This should be part of amdgpu. All of the code except for this one function is there already. Having this weird build setup for a single source file with a single function is silly. I have a patch for that too but didn't know if there was a reason for the way it's structured that isn't immediately visible. > - add forward declarations in acp/include/acp_gfx_if.h and move the > cgs* includes where needed (acp/acp_hw.c and amdgpu/amdgpu_acp.c) > - apply similar polish for amdgpu/amdgpu_acp.h. > - drop the (unneeded ?) include of amdgpu_acp.h include from amdgpu/vi.c > - kill off amdgpu_acp::private. Afaict there's not a single place (as > of 95306975e9dd38ba2775dd96cb29987ecc7d9360) that actually defines the > amd_acp_private struct. Is something broken on my end or this does not > build without warnings/errors ? > - kill off amdgpu_acp::acp_genpd::cgs_dev (use amdgpu_acp::cgs_device > directly) and inline the ::acp_genpd::gpd into amdgpu_acp. This starts getting into the code itself and I don't have hardware to test with, so I didn't dig in at all. -Jeff -- Jeff Mahoney SUSE Labs -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/225b9e59/attachment.sig>
[PATCH v4 5/7] drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties
On 25/05/16 23:43, Jyri Sarha wrote:
> Use new drm_crtc_enable_color_mgmt() to enable gamma lut properties.
You could move the color-mgmt patches to the beginning of the series,
and add the omapdrm ones on top of those.
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 5b7f6f5..e03b349 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -556,16 +556,10 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>* gamma table is not supprted.
>*/
> if (dispc_mgr_gamma_size(channel)) {
> - struct drm_mode_config *config = &dev->mode_config;
> - uint gamma_size = 256;
> + uint gamma_lut_size = 256;
>
> - drm_mode_crtc_set_gamma_size(crtc, gamma_size);
> -
> - drm_object_attach_property(&crtc->base,
> -config->gamma_lut_property, 0);
> - drm_object_attach_property(&crtc->base,
> -config->gamma_lut_size_property,
> -gamma_size);
> + drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
> + drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
Any reason drm_crtc_enable_color_mgmt() couldn't also call
drm_mode_crtc_set_gamma_size()?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/90d395d9/attachment.sig>
[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
https://bugs.freedesktop.org/show_bug.cgi?id=95017 --- Comment #13 from Mathieu Malaterre --- Patch has also been submitted to dri-devel: https://lists.freedesktop.org/archives/dri-devel/2016-May/107479.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/1ff119fe/attachment.html>
[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
https://bugs.freedesktop.org/show_bug.cgi?id=95017 --- Comment #12 from Mathieu Malaterre --- Patch has been submitted to mesa-dev: https://lists.freedesktop.org/archives/mesa-dev/2016-May/115453.html and Reviewed-By Christian König -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/2bc44840/attachment.html>
[PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.
Hello Yakir, On 05/26/2016 05:34 AM, Yakir Yang wrote: > Hi Javier, > > On 05/24/2016 01:01 PM, Yakir Yang wrote: >> Hi all, >> >> This series have been posted about one month, still no comments, help here :( > This series works rightly on Rockchip platform, and most of them haven't > touch the > common analogix_dp driver (except for the hotplug fixed). So i guess Exynos > platform > should also happy with this changes. > > But not sure about that. So, is it possible that you could help to check this > on Exynos > Chromebook, if so i would be very grateful about that. > Of course, I' ll test. Could you please provide me a branch that I can pull directly to avoid cherry-picking all the patches from the list? > Thanks, > - Yakir >> Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America
[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
https://bugzilla.kernel.org/show_bug.cgi?id=88861
--- Comment #21 from Lukas Wunner ---
If you revert 4eebd5a4e7269 ("apple-gmux: lock iGP IO to protect from vgaarb
changes") instead of 704ab614ec12, does the issue go away?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4eebd5a4e7269
--
You are receiving this mail because:
You are the assignee for the bug.
fsl-dcu not works on latest "drm-next"
Hi Mark,
> You've not specifically described the problem here - what are the endiannesses
> of both the CPU and the device you're talking to? What specifically is the
> endianess problem you are seeing, what are you seeing and what do you
> expect to see?
>
The CPU is little endian and the device DCU is big endian, specified big-endian
in DTS,
And here is my DTS and regmap_config,
Specified "big-endian" in DTS,
dcu: dcu at 2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <&platform_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};
I can't tell the difference of "reg_format_endian" and " val_format_endian ",
so I had tried four conditions. And all failed.
static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
// .reg_format_endian = REGMAP_ENDIAN_BIG, // .val_format_endian =
REGMAP_ENDIAN_BIG,
.volatile_reg = fsl_dcu_drm_is_volatile_reg, };
I expect that regmap write as big endian, and I am seeing is regmap write as
little endian.
Thanks,
Best Regards,
Meng Yi
fsl-dcu not works on latest "drm-next"
Hi Alexander,
> From your backtrace I guess wait_event_timeout is called in some atomic
> context (might_sleep(); is called inside wait_event_timeout). This has nothing
> to do with regmap.
>
Here is my view of point:
Since IRQ setup codes using regmap, and which is not setup properly, so
wait_event_timeout.
>
> The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> could successfully probe DCU.
Thanks for your information.
DCU was able to be probed without those patches, and DCU still not works with
those patches.
And here is my DTS and regmap_config,
Specified "big-endian" in DTS,
dcu: dcu at 2ce {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce 0x0 0x1>;
interrupts = ;
clocks = <&platform_clk 0>;
clock-names = "dcu";
big-endian;
status = "disabled";
};
I can't tell the difference of "reg_format_endian" and " val_format_endian ",
so I had tried four conditions.
static const struct regmap_config fsl_dcu_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
.cache_type = REGCACHE_RBTREE,
// .reg_format_endian = REGMAP_ENDIAN_BIG,
// .val_format_endian = REGMAP_ENDIAN_BIG,
.volatile_reg = fsl_dcu_drm_is_volatile_reg,
};
Thanks,
Best Regards,
Meng Yi
[PATCH] drm: Store the plane's index
On Thu, May 26, 2016 at 01:17:18PM +0100, Chris Wilson wrote:
> Currently the plane's index is determined by walking the list of all
> planes in the mode and finding the position of that plane in the list. A
> linear walk, especially a linear walk within a linear walk as frequently
> conceived by i915.ko [O(N^2)] quickly comes to dominate profiles.
>
> The plane's index is constant for as long as no earlier planes are
> removed from the list. For most drivers, planes are static, determined
> at boot and then untouched until shutdown. Storing the index upon
> construction and then only walking the tail upon removal should
> be a major improvement for all.
>
> v2: Convert drm_crtc_index() and drm_encoder_index() as well.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Matt Roper
> Cc: Ville Syrjälä
Looks good to me.
Reviewed-by: Matt Roper
Your commit message says "most drivers" have static
planes/crtcs/encoders...are there any drivers today that this isn't true
for? Wouldn't we need special locking for list iteration in general
like we have for connectors if that was the case?
Matt
> ---
> drivers/gpu/drm/drm_crtc.c | 98
> ++
> include/drm/drm_crtc.h | 25 ++--
> 2 files changed, 43 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d2a6d958ca76..4d978099aa17 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -692,7 +692,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> crtc->base.properties = &crtc->properties;
>
> list_add_tail(&crtc->head, &config->crtc_list);
> - config->num_crtc++;
> + crtc->index = config->num_crtc++;
>
> crtc->primary = primary;
> crtc->cursor = cursor;
> @@ -721,6 +721,11 @@ EXPORT_SYMBOL(drm_crtc_init_with_planes);
> void drm_crtc_cleanup(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> + struct drm_crtc *other;
> +
> + other = list_next_entry(crtc, head);
> + list_for_each_entry_from(other, &dev->mode_config.crtc_list, head)
> + other->index--;
>
> kfree(crtc->gamma_store);
> crtc->gamma_store = NULL;
> @@ -741,29 +746,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_cleanup);
>
> -/**
> - * drm_crtc_index - find the index of a registered CRTC
> - * @crtc: CRTC to find index for
> - *
> - * Given a registered CRTC, return the index of that CRTC within a DRM
> - * device's list of CRTCs.
> - */
> -unsigned int drm_crtc_index(struct drm_crtc *crtc)
> -{
> - unsigned int index = 0;
> - struct drm_crtc *tmp;
> -
> - drm_for_each_crtc(tmp, crtc->dev) {
> - if (tmp == crtc)
> - return index;
> -
> - index++;
> - }
> -
> - BUG();
> -}
> -EXPORT_SYMBOL(drm_crtc_index);
> -
> /*
> * drm_mode_remove - remove and free a mode
> * @connector: connector list to modify
> @@ -1166,7 +1148,7 @@ int drm_encoder_init(struct drm_device *dev,
> }
>
> list_add_tail(&encoder->head, &dev->mode_config.encoder_list);
> - dev->mode_config.num_encoder++;
> + encoder->index = dev->mode_config.num_encoder++;
>
> out_put:
> if (ret)
> @@ -1180,29 +1162,6 @@ out_unlock:
> EXPORT_SYMBOL(drm_encoder_init);
>
> /**
> - * drm_encoder_index - find the index of a registered encoder
> - * @encoder: encoder to find index for
> - *
> - * Given a registered encoder, return the index of that encoder within a DRM
> - * device's list of encoders.
> - */
> -unsigned int drm_encoder_index(struct drm_encoder *encoder)
> -{
> - unsigned int index = 0;
> - struct drm_encoder *tmp;
> -
> - drm_for_each_encoder(tmp, encoder->dev) {
> - if (tmp == encoder)
> - return index;
> -
> - index++;
> - }
> -
> - BUG();
> -}
> -EXPORT_SYMBOL(drm_encoder_index);
> -
> -/**
> * drm_encoder_cleanup - cleans up an initialised encoder
> * @encoder: encoder to cleanup
> *
> @@ -1211,6 +1170,11 @@ EXPORT_SYMBOL(drm_encoder_index);
> void drm_encoder_cleanup(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> + struct drm_encoder *other;
> +
> + other = list_next_entry(encoder, head);
> + list_for_each_entry_from(other, &dev->mode_config.encoder_list, head)
> + other->index--;
>
> drm_modeset_lock_all(dev);
> drm_mode_object_unregister(dev, &encoder->base);
> @@ -1300,7 +1264,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> plane->type = type;
>
> list_add_tail(&plane->head, &config->plane_list);
> - config->num_total_plane++;
> + plane->index = config->num_total_plane++;
> if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> config->num_overlay_plane++;
>
> @@ -1367,6 +1331,7 @@ EXPORT_SYMBOL
[Bug 95094] Flat uniform gets overwrites previous uniform
https://bugs.freedesktop.org/show_bug.cgi?id=95094 pavol at klacansky.com changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from pavol at klacansky.com --- No, sorry. I even forgot to which project it belongs and can't find anything with grep. I am using explicit layouts everywhere. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160526/ea542855/attachment.html>
