[RESEND PATCH v2 3/3] drm: tegra: use of_get_i2c_adapter_by_node interface
This change is needed to properly lock I2C bus driver, which serves
DDC, otherwise there is an error in I2C bus driver user counting.
Note, that prior to the change put_device() coupled with
of_find_i2c_adapter_by_node() was missing on error path of
tegra_output_probe().
Signed-off-by: Vladimir Zapolskiy
Cc: Thierry Reding
---
drivers/gpu/drm/tegra/output.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..1edfde77bb6d 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -113,14 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
- output->ddc = of_find_i2c_adapter_by_node(ddc);
+ output->ddc = of_get_i2c_adapter_by_node(ddc);
+ of_node_put(ddc);
if (!output->ddc) {
err = -EPROBE_DEFER;
- of_node_put(ddc);
return err;
}
-
- of_node_put(ddc);
}
output->hpd_gpio = of_get_named_gpio_flags(output->of_node,
@@ -133,14 +131,13 @@ int tegra_output_probe(struct tegra_output *output)
"HDMI hotplug detect");
if (err < 0) {
dev_err(output->dev, "gpio_request_one(): %d\n", err);
- return err;
+ goto i2c_release;
}
err = gpio_to_irq(output->hpd_gpio);
if (err < 0) {
dev_err(output->dev, "gpio_to_irq(): %d\n", err);
- gpio_free(output->hpd_gpio);
- return err;
+ goto gpio_release;
}
output->hpd_irq = err;
@@ -153,8 +150,7 @@ int tegra_output_probe(struct tegra_output *output)
if (err < 0) {
dev_err(output->dev, "failed to request IRQ#%u: %d\n",
output->hpd_irq, err);
- gpio_free(output->hpd_gpio);
- return err;
+ goto gpio_release;
}
output->connector.polled = DRM_CONNECTOR_POLL_HPD;
@@ -168,6 +164,14 @@ int tegra_output_probe(struct tegra_output *output)
}
return 0;
+
+gpio_release:
+ gpio_free(output->hpd_gpio);
+
+i2c_release:
+ i2c_put_adapter(output->ddc);
+
+ return err;
}
void tegra_output_remove(struct tegra_output *output)
@@ -177,8 +181,7 @@ void tegra_output_remove(struct tegra_output *output)
gpio_free(output->hpd_gpio);
}
- if (output->ddc)
- put_device(&output->ddc->dev);
+ i2c_put_adapter(output->ddc);
}
int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
--
2.8.1
[RESEND PATCH v2 2/3] drm: tilcdc: use of_get_i2c_adapter_by_node interface
This change is needed to properly lock I2C bus driver, which serves
DDC, otherwise there is an error in I2C bus driver user counting.
Prior to this change i2c_put_adapter() is misused, which may lead
to an overflow over zero of I2C bus driver user counter.
Signed-off-by: Vladimir Zapolskiy
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 6b8c5b3bf588..73f29dc75d33 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -331,15 +331,13 @@ static int tfp410_probe(struct platform_device *pdev)
goto fail;
}
- tfp410_mod->i2c = of_find_i2c_adapter_by_node(i2c_node);
+ tfp410_mod->i2c = of_get_i2c_adapter_by_node(i2c_node);
+ of_node_put(i2c_node);
if (!tfp410_mod->i2c) {
dev_err(&pdev->dev, "could not get i2c\n");
- of_node_put(i2c_node);
goto fail;
}
- of_node_put(i2c_node);
-
tfp410_mod->gpio = of_get_named_gpio_flags(node, "powerdn-gpio",
0, NULL);
if (tfp410_mod->gpio < 0) {
--
2.8.1
[RESEND PATCH v2 1/3] drm: dw_hdmi: use of_get_i2c_adapter_by_node interface
This change is needed to properly lock I2C bus driver, which serves
DDC.
The change fixes an overflow over zero of I2C bus driver user counter:
root at imx6q:~# lsmod
Not tainted
dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
dw_hdmi_imx 3498 0 - Live 0xbf00d000
dw_hdmi 16398 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000
i2c_imx 16687 0 - Live 0xbf017000
root at imx6q:~# rmmod dw_hdmi_imx
root at imx6q:~# lsmod
Not tainted
dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000
dw_hdmi 16398 1 dw_hdmi_ahb_audio, Live 0xbf004000
i2c_imx 16687 -1 - Live 0xbf017000
^^
root at imx6q:~# rmmod i2c_imx
rmmod: ERROR: Module i2c_imx is in use
Note that prior to this change put_device() coupled with
of_find_i2c_adapter_by_node() was missing on error path of
dw_hdmi_bind(), added i2c_put_adapter() there along with the change.
Signed-off-by: Vladimir Zapolskiy
Cc: Russell King
Cc: Philipp Zabel
Cc: Fabio Estevam
---
drivers/gpu/drm/bridge/dw-hdmi.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab47341658..ce3527cd0d25 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1686,7 +1686,7 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
- hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
@@ -1698,20 +1698,22 @@ int dw_hdmi_bind(struct device *dev, struct device
*master,
}
hdmi->regs = devm_ioremap_resource(dev, iores);
- if (IS_ERR(hdmi->regs))
- return PTR_ERR(hdmi->regs);
+ if (IS_ERR(hdmi->regs)) {
+ ret = PTR_ERR(hdmi->regs);
+ goto err_res;
+ }
hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
if (IS_ERR(hdmi->isfr_clk)) {
ret = PTR_ERR(hdmi->isfr_clk);
dev_err(hdmi->dev, "Unable to get HDMI isfr clk: %d\n", ret);
- return ret;
+ goto err_res;
}
ret = clk_prepare_enable(hdmi->isfr_clk);
if (ret) {
dev_err(hdmi->dev, "Cannot enable HDMI isfr clock: %d\n", ret);
- return ret;
+ goto err_res;
}
hdmi->iahb_clk = devm_clk_get(hdmi->dev, "iahb");
@@ -1797,6 +1799,8 @@ err_iahb:
clk_disable_unprepare(hdmi->iahb_clk);
err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
+err_res:
+ i2c_put_adapter(hdmi->ddc);
return ret;
}
--
2.8.1
[RESEND PATCH v2 0/3] drm: fix invalid user counters of i2c bus device
This is a resend of the changes, the bugs were identified and fixed one year ago, however the fixes are still not found in the mainline: http://dri-devel.freedesktop.narkive.com/cWNFTOZC/patch-v2-0-3-drm-fix-i2c-adapter-device-driver-user-counter of_find_i2c_adapter_by_node() call requires quite often missing put_device(), and i2c_put_adapter() releases a device locked by i2c_get_adapter() only. Below is a common error reproduction scenario as a result of the misusage described above, this is run on iMX6 platform 4.8.0-rc1 with HDMI and I2C bus drivers compiled as kernel modules for clarity after changing arch/arm/configs/imx_v6_v7_defconfig: -CONFIG_I2C_IMX=y +CONFIG_I2C_IMX=m -CONFIG_DRM_IMX_HDMI=y +CONFIG_DRM_IMX_HDMI=m root at imx6q:~# lsmod Not tainted dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 dw_hdmi_imx 3498 0 - Live 0xbf00d000 dw_hdmi 16398 2 dw_hdmi_ahb_audio,dw_hdmi_imx, Live 0xbf004000 i2c_imx 16687 0 - Live 0xbf017000 root at imx6q:~# rmmod dw_hdmi_imx root at imx6q:~# lsmod Not tainted dw_hdmi_ahb_audio 4082 0 - Live 0xbf02c000 dw_hdmi 16398 1 dw_hdmi_ahb_audio, Live 0xbf004000 i2c_imx 16687 -1 - Live 0xbf017000 ^^ root at imx6q:~# rmmod i2c_imx rmmod: ERROR: Module i2c_imx is in use To fix existing users of these interfaces use of_get_i2c_adapter_by_node() interface, which is similar to i2c_get_adapter() in sense that an I2C bus device driver found and locked by a user can be correctly unlocked by i2c_put_adapter() call. Changes from v2 to v2 resend: - none Changes from v1 to v2: - none, this series is a straightforward bugfix, v1 was a blend of I2C core changes, bugfixes and improvements Vladimir Zapolskiy (3): drm: dw_hdmi: use of_get_i2c_adapter_by_node interface drm: tilcdc: use of_get_i2c_adapter_by_node interface drm: tegra: use of_get_i2c_adapter_by_node interface drivers/gpu/drm/bridge/dw-hdmi.c | 14 +- drivers/gpu/drm/tegra/output.c | 25 ++--- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 ++ 3 files changed, 25 insertions(+), 20 deletions(-) -- 2.8.1
[PATCH v3 1/3] drm: add SimpleDRM driver
Den 16.08.2016 17:25, skrev Daniel Vetter:
> On Tue, Aug 16, 2016 at 02:58:38PM +0200, Noralf Trønnes wrote:
>> Den 15.08.2016 08:59, skrev Daniel Vetter:
>>> On Sun, Aug 14, 2016 at 06:52:04PM +0200, Noralf Trønnes wrote:
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create dumb-buffers which can be blit into the real
framebuffer similar to UDL. No access to the real framebuffer is allowed
(compared to earlier version of this driver) to avoid security issues.
Furthermore, this way we can support arbitrary modes as long as we have a
conversion-helper.
The driver was originally written by David Herrmann in 2014.
My main contribution is to make use of drm_simple_kms_helper and
rework the probe path to avoid use of the deprecated drm_platform_init()
and drm_driver.{load,unload}().
Additions have also been made for later changes to the Device Tree binding
document, like support for clocks, regulators and having the node under
/chosen. This code was lifted verbatim from simplefb.c.
Cc: dh.herrmann at gmail.com
Cc: libv at skynet.be
Signed-off-by: Noralf Trønnes
>>
>>
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_gem.c
b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
new file mode 100644
index 000..81bd7c5
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
>>
>>
+struct sdrm_gem_object *sdrm_gem_alloc_object(struct drm_device *ddev,
+size_t size)
+{
+ struct sdrm_gem_object *obj;
+
+ WARN_ON(!size || (size & ~PAGE_MASK) != 0);
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return NULL;
+
+ drm_gem_private_object_init(ddev, &obj->base, size);
+ return obj;
+}
+
+void sdrm_gem_free_object(struct drm_gem_object *gobj)
+{
+ struct sdrm_gem_object *obj = to_sdrm_bo(gobj);
+ struct drm_device *ddev = gobj->dev;
+
+ if (obj->pages) {
+ /* kill all user-space mappings */
+ drm_vma_node_unmap(&gobj->vma_node,
+ ddev->anon_inode->i_mapping);
+ sdrm_gem_put_pages(obj);
+ }
+
+ if (gobj->import_attach)
+ drm_prime_gem_destroy(gobj, obj->sg);
+
+ drm_gem_free_mmap_offset(gobj);
+ drm_gem_object_release(gobj);
+ kfree(obj);
+}
+
+int sdrm_dumb_create(struct drm_file *dfile, struct drm_device *ddev,
+ struct drm_mode_create_dumb *args)
+{
+ struct sdrm_gem_object *obj;
+ int r;
+
+ if (args->flags)
+ return -EINVAL;
+
+ /* overflow checks are done by DRM core */
+ args->pitch = (args->bpp + 7) / 8 * args->width;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
+
+ obj = sdrm_gem_alloc_object(ddev, args->size);
+ if (!obj)
+ return -ENOMEM;
+
+ r = drm_gem_handle_create(dfile, &obj->base, &args->handle);
+ if (r) {
+ drm_gem_object_unreference_unlocked(&obj->base);
+ return r;
+ }
+
+ /* handle owns a reference */
+ drm_gem_object_unreference_unlocked(&obj->base);
+ return 0;
+}
+
+int sdrm_dumb_destroy(struct drm_file *dfile, struct drm_device *ddev,
+uint32_t handle)
+{
+ return drm_gem_handle_delete(dfile, handle);
+}
>>> I wonder whether some dumb+gem helpers wouldn't be useful to roll out. At
>>> least drm_dumb_gem_destroy.c would be pretty simple.
>> There's already a drm_gem_dumb_destroy() in drm_gem.c
>>
>> The drm_driver->gem_create_object callback makes it possible to do a
>> generic dumb create:
>>
>> int drm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
>> struct drm_mode_create_dumb *args)
>> {
>> struct drm_gem_object *obj;
>> int ret;
>>
>> if (!dev->driver->gem_create_object)
>> return -EINVAL;
>>
>> args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> args->size = args->pitch * args->height;
>>
>> obj = dev->driver->gem_create_object(dev, args->size);
>> if (!obj)
>> return -ENOMEM;
>>
>> ret = drm_gem_handle_create(file, obj, &args->handle);
>> drm_gem_object_unreference_unlocked(obj);
>>
>> return ret;
>> }
>> EXPORT_SYMBOL(drm_gem_dumb_create);
>>
>> struct drm_gem_object *sdrm_gem_create_object(struct drm_device *ddev,
>>size_t size)
>> {
>> struct sdrm_gem_object *sobj;
>>
>> sobj = sdrm_gem_alloc_object(ddev, size);
>> if (!sobj)
>> return ERR_PTR(-ENOMEM);
>>
>> return &sobj->base;
>> }
>>
+
+i
[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10
https://bugs.freedesktop.org/show_bug.cgi?id=97371 --- Comment #2 from Armin K --- bbec97aae660adafa5208c5defc54e3cbbe6b129 is the first bad commit commit bbec97aae660adafa5208c5defc54e3cbbe6b129 Author: Christian König Date: Tue Jul 5 21:07:17 2016 +0200 drm/amdgpu: add a fence timeout for the IB tests v2 10ms should be enough for now. v2: fix some typos in CIK code Signed-off-by: Christian König Reviewed-by: Chunming Zhou Reviewed-by: Edward O'Callaghan Signed-off-by: Alex Deucher -- 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/20160816/7f2be3df/attachment.html>
[PATCH v2 0/6] drm/rockchip: Some patches to update the PSR series
On Aug 16, 2016 7:41 PM, "Yakir Yang" wrote: > > Sean, > > Thanks a lot for your good fixes. I have reviewed most of them, and all looks good to me. > > But I got a question for merging things. My PSR patch set still under reviewing, haven't been picked up Mark or other maintainers. I've picked them up in my tree. I'll send a pull request to Dave once all of the dependencies have been reviewed (marked NEEDS REVIEW). Sean > Feel a little bit embarrassed, how could we handle this situation ? > > - Yakir > > > On 08/17/2016 09:11 AM, Sean Paul wrote: >> >> This is a follow-on set to Yakir's original PSR set here: >> https://lkml.org/lkml/2016/7/24/34 >> and applies to the for-next branch at: >> https://cgit.freedesktop.org/~seanpaul/dogwood >> >> There are a few issues with the code that needed to be >> shored up. >> (1) The use of mutexes instead of spinlocks caused issues calling the >> psr functions from vblank_enable/disable. >> (2) The proliferation of workers due to (1) >> (3) A bunch of races due to (2) >> (4) vblank is not enabled unless an event is requested, this breaks >> a lot of things, but most noticeable was cursor. >> >> Changes in v2: >> - Rebased on https://cgit.freedesktop.org/~seanpaul/dogwood >> instead of random on-list patches (some of which had drifted) >> - Added the "small fixes" patch to catch some nits >> >> >> Sean Paul (6): >>drm/rockchip: Convert psr_list_mutex to spinlock and use it >>drm/rockchip: Don't use a delayed worker for psr state changes >>drm/rockchip: Use a spinlock to protect psr state >>drm/rockchip: A couple small fixes to psr >>drm/rockchip: Improve analogix-dp psr handling >>drm/rockchip: Enable vblank without event >> >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 -- >> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- >> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +- >> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 90 - >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++-- >> 5 files changed, 69 insertions(+), 59 deletions(-) >> > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160816/53708a28/attachment-0001.html>
[Bug 93475] Saints Row IV causes GPU lockup on Linux
https://bugs.freedesktop.org/show_bug.cgi?id=93475 --- Comment #4 from Michael Stenzel --- Hello, I have a HD 5870, with radeon module. Today I upgraded to kernel 4.7 and mesa git from a few hours ago. Can confirm this issue with SR3, still locks the GPU up: [ 2598.025126] radeon :01:00.0: ring 3 stalled for more than 10025msec [ 2598.025135] radeon :01:00.0: GPU lockup (current fence id 0x0005d84c last fence id 0x0005d84d on ring 3) after `export R600_DEBUG=nosb` the game seems to work fine here (played first level for a few minutes). -- 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/20160816/6c4bed54/attachment.html>
[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10
https://bugs.freedesktop.org/show_bug.cgi?id=97371 --- Comment #1 from Alex Deucher --- Can you bisect? -- 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/20160816/2b103ec0/attachment.html>
[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10
eded [ 15.997405] [drm] ib test on ring 3 succeeded [ 15.997435] [drm] ib test on ring 4 succeeded [ 15.997466] [drm] ib test on ring 5 succeeded [ 15.997495] [drm] ib test on ring 6 succeeded [ 15.997526] [drm] ib test on ring 7 succeeded [ 15.997556] [drm] ib test on ring 8 succeeded [ 15.997612] [drm:sdma_v2_4_ring_test_ib [amdgpu]] *ERROR* amdgpu: fence wait failed (1000). [ 15.997654] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on ring 9 (1000). [ 15.997713] [drm:sdma_v2_4_ring_test_ib [amdgpu]] *ERROR* amdgpu: fence wait failed (1000). [ 15.997749] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on ring 10 (1000). -- 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/20160816/24b08efb/attachment-0001.html>
[Bug 97369] AMDGPU/Iceland hangs kernel 4.8-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=97369 Armin K changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Armin K --- Applying patch linked from Comment 1 fixes the issue. -- 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/20160816/cae764da/attachment.html>
[Bug 97039] The Talos Principle and Serious Sam 3 GPU faults
https://bugs.freedesktop.org/show_bug.cgi?id=97039 Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed: What|Removed |Added CC||0xe2.0x9a.0x9b at gmail.com --- Comment #8 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to smoki from comment #2) > Test is on Kabini APU (i have Bonaire and Kaveri so i might test that too), > but someone on irc already mentioned it happens with amdgpu on Bonaire... so > yup if it does not happen with Tonga it might be CIK related. I have Kaveri iGPU and Talos Principle. I can try to run Talos Principle on Kaveri later this day (machine needs to be rebooted to enable the iGPU). Were you able to reproduce the issue on your Kaveri iGPU, or is it just reproducible on Kabini? -- 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/20160816/74a76d00/attachment.html>
[PATCH v2 6/6] drm/rockchip: Enable vblank without event
vblank should be enabled regardless of whether an event
is expected back. This is especially important for a cursor
plane.
Signed-off-by: Sean Paul
---
Changes in v2:
- Rebased on
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d1e0e06..1787084 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -112,6 +112,7 @@ struct vop {
struct device *dev;
struct drm_device *drm_dev;
bool is_enabled;
+ bool vblank_active;
/* mutex vsync_ work */
struct mutex vsync_mutex;
@@ -1107,10 +1108,11 @@ static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
struct vop *vop = to_vop(crtc);
spin_lock_irq(&crtc->dev->event_lock);
- if (crtc->state->event) {
- WARN_ON(drm_crtc_vblank_get(crtc) != 0);
- WARN_ON(vop->event);
+ vop->vblank_active = true;
+ WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+ WARN_ON(vop->event);
+ if (crtc->state->event) {
vop->event = crtc->state->event;
crtc->state->event = NULL;
}
@@ -1197,12 +1199,14 @@ static void vop_handle_vblank(struct vop *vop)
spin_lock_irqsave(&drm->event_lock, flags);
if (vop->event) {
-
drm_crtc_send_vblank_event(crtc, vop->event);
- drm_crtc_vblank_put(crtc);
vop->event = NULL;
}
+ if (vop->vblank_active) {
+ vop->vblank_active = false;
+ drm_crtc_vblank_put(crtc);
+ }
spin_unlock_irqrestore(&drm->event_lock, flags);
if (!completion_done(&vop->wait_update_complete))
@@ -1472,6 +1476,7 @@ static int vop_initial(struct vop *vop)
clk_disable(vop->aclk);
vop->is_enabled = false;
+ vop->vblank_active = false;
return 0;
--
2.8.0.rc3.226.g39d4020
[PATCH v2 5/6] drm/rockchip: Improve analogix-dp psr handling
Remove the delayed worker, opting instead for the non-delayed
variety. Also introduce a lock to ensure we don't have races
with the worker and psr_state. Finally, cancel and wait for
the worker to finish when disabling the bridge.
Signed-off-by: Sean Paul
---
Changes in v2:
- Rebased on
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d6d0751..439b933 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -42,7 +42,6 @@
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
-#define PSR_SET_DELAY_TIME msecs_to_jiffies(10)
#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS 100
#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
@@ -72,7 +71,8 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
- struct delayed_work psr_work;
+ struct work_struct psr_work;
+ spinlock_t psr_lock;
unsigned int psr_state;
const struct rockchip_dp_chip_data *data;
@@ -83,25 +83,29 @@ struct rockchip_dp_device {
static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
{
struct rockchip_dp_device *dp = to_dp(encoder);
+ unsigned long flags;
dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+ spin_lock_irqsave(&dp->psr_lock, flags);
if (enabled)
dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
else
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
- schedule_delayed_work(&dp->psr_work, PSR_SET_DELAY_TIME);
+ schedule_work(&dp->psr_work);
+ spin_unlock_irqrestore(&dp->psr_lock, flags);
}
static void analogix_dp_psr_work(struct work_struct *work)
{
struct rockchip_dp_device *dp =
- container_of(work, typeof(*dp), psr_work.work);
+ container_of(work, typeof(*dp), psr_work);
struct drm_crtc *crtc = dp->encoder.crtc;
int psr_state = dp->psr_state;
int vact_end;
int ret;
+ unsigned long flags;
if (!crtc)
return;
@@ -115,10 +119,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
return;
}
+ spin_lock_irqsave(&dp->psr_lock, flags);
if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
+ spin_unlock_irqrestore(&dp->psr_lock, flags);
}
static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -135,6 +141,8 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data
*plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
+ cancel_work_sync(&dp->psr_work);
+
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -390,8 +398,9 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
+ spin_lock_init(&dp->psr_lock);
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
- INIT_DELAYED_WORK(&dp->psr_work, analogix_dp_psr_work);
+ INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
--
2.8.0.rc3.226.g39d4020
[PATCH v2 4/6] drm/rockchip: A couple small fixes to psr
A few things that need tidying up, no functional changes.
Signed-off-by: Sean Paul
---
Changes in v2:
- Introduced
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 5bd54f2..c6ac5d0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -62,27 +62,25 @@ static void psr_set_state_locked(struct psr_drv *psr, enum
psr_state state)
* Allowed finite state machine:
*
* PSR_ENABLE < = = = = = > PSR_FLUSH
- * | ^|
- * | ||
- * v ||
+* | ^|
+* | ||
+* v ||
* PSR_DISABLE < - - - - - - - - -
*/
-
- /* Forbid no state change */
if (state == psr->state)
return;
- /* Forbid DISABLE change to FLUSH */
+ /* Requesting a flush when disabled is a noop */
if (state == PSR_FLUSH && psr->state == PSR_DISABLE)
return;
psr->state = state;
- /* Allow but no need hardware change, just need assign the state */
+ /* Already disabled in flush, change the state, but not the hardware */
if (state == PSR_DISABLE && psr->state == PSR_FLUSH)
return;
- /* Refact to hardware state change */
+ /* Actually commit the state change to hardware */
switch (psr->state) {
case PSR_ENABLE:
psr->set(psr->encoder, true);
@@ -109,10 +107,7 @@ static void psr_flush_handler(unsigned long data)
struct psr_drv *psr = (struct psr_drv *)data;
unsigned long flags;
- if (!psr)
- return;
-
- /* State changed between flush time, then keep it */
+ /* If the state has changed since we initiated the flush, do nothing */
spin_lock_irqsave(&psr->lock, flags);
if (psr->state == PSR_FLUSH)
psr_set_state_locked(psr, PSR_ENABLE);
--
2.8.0.rc3.226.g39d4020
[PATCH v2 3/6] drm/rockchip: Use a spinlock to protect psr state
The handling of psr state is racey, shore that up with
a per-psr driver lock.
Signed-off-by: Sean Paul
---
Changes in v2:
- Rebased on
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 4c645d7..5bd54f2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -30,6 +30,7 @@ struct psr_drv {
struct list_headlist;
struct drm_encoder *encoder;
+ spinlock_t lock;
enum psr_state state;
struct timer_list flush_timer;
@@ -55,7 +56,7 @@ out:
return psr;
}
-static void psr_set_state(struct psr_drv *psr, enum psr_state state)
+static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
{
/*
* Allowed finite state machine:
@@ -75,7 +76,6 @@ static void psr_set_state(struct psr_drv *psr, enum psr_state
state)
if (state == PSR_FLUSH && psr->state == PSR_DISABLE)
return;
- /* Only wrote in this work, no need lock protection */
psr->state = state;
/* Allow but no need hardware change, just need assign the state */
@@ -95,18 +95,28 @@ static void psr_set_state(struct psr_drv *psr, enum
psr_state state)
}
}
+static void psr_set_state(struct psr_drv *psr, enum psr_state state)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&psr->lock, flags);
+ psr_set_state_locked(psr, state);
+ spin_unlock_irqrestore(&psr->lock, flags);
+}
+
static void psr_flush_handler(unsigned long data)
{
struct psr_drv *psr = (struct psr_drv *)data;
+ unsigned long flags;
if (!psr)
return;
/* State changed between flush time, then keep it */
- if (psr->state != PSR_FLUSH)
- return;
-
- psr_set_state(psr, PSR_ENABLE);
+ spin_lock_irqsave(&psr->lock, flags);
+ if (psr->state == PSR_FLUSH)
+ psr_set_state_locked(psr, PSR_ENABLE);
+ spin_unlock_irqrestore(&psr->lock, flags);
}
/**
@@ -167,9 +177,6 @@ void rockchip_drm_psr_flush(struct drm_device *dev)
spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
- if (psr->state == PSR_DISABLE)
- continue;
-
mod_timer(&psr->flush_timer,
round_jiffies_up(jiffies + PSR_FLUSH_TIMEOUT));
@@ -202,6 +209,7 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
return -ENOMEM;
setup_timer(&psr->flush_timer, psr_flush_handler, (unsigned long)psr);
+ spin_lock_init(&psr->lock);
psr->state = PSR_DISABLE;
psr->encoder = encoder;
--
2.8.0.rc3.226.g39d4020
[PATCH v2 2/6] drm/rockchip: Don't use a delayed worker for psr state changes
The delayed worker isn't needed and is racey. Remove it and do
the state change in line.
Signed-off-by: Sean Paul
---
Changes in v2:
- Rebased on
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 38 -
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index bd25273..4c645d7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -19,7 +19,6 @@
#include "rockchip_drm_psr.h"
#define PSR_FLUSH_TIMEOUT msecs_to_jiffies(3000) /* 3 seconds */
-#define PSR_SET_DELAY_TIME msecs_to_jiffies(10)
enum psr_state {
PSR_FLUSH,
@@ -31,11 +30,8 @@ struct psr_drv {
struct list_headlist;
struct drm_encoder *encoder;
- enum psr_state request_state;
enum psr_state state;
- struct delayed_work state_work;
-
struct timer_list flush_timer;
void (*set)(struct drm_encoder *encoder, bool enable);
@@ -59,11 +55,8 @@ out:
return psr;
}
-static void psr_state_work(struct work_struct *work)
+static void psr_set_state(struct psr_drv *psr, enum psr_state state)
{
- struct psr_drv *psr = container_of(work, typeof(*psr), state_work.work);
- enum psr_state request_state = psr->request_state;
-
/*
* Allowed finite state machine:
*
@@ -75,24 +68,22 @@ static void psr_state_work(struct work_struct *work)
*/
/* Forbid no state change */
- if (request_state == psr->state)
+ if (state == psr->state)
return;
/* Forbid DISABLE change to FLUSH */
- if (request_state == PSR_FLUSH && psr->state == PSR_DISABLE)
+ if (state == PSR_FLUSH && psr->state == PSR_DISABLE)
return;
+ /* Only wrote in this work, no need lock protection */
+ psr->state = state;
+
/* Allow but no need hardware change, just need assign the state */
- if (request_state == PSR_DISABLE && psr->state == PSR_FLUSH) {
- psr->state = request_state;
+ if (state == PSR_DISABLE && psr->state == PSR_FLUSH)
return;
- }
-
- /* Only wrote in this work, no need lock protection */
- psr->state = request_state;
/* Refact to hardware state change */
- switch (request_state) {
+ switch (psr->state) {
case PSR_ENABLE:
psr->set(psr->encoder, true);
break;
@@ -104,13 +95,6 @@ static void psr_state_work(struct work_struct *work)
}
}
-static void psr_set_state(struct psr_drv *psr, enum psr_state state)
-{
- psr->request_state = state;
-
- schedule_delayed_work(&psr->state_work, PSR_SET_DELAY_TIME);
-}
-
static void psr_flush_handler(unsigned long data)
{
struct psr_drv *psr = (struct psr_drv *)data;
@@ -119,7 +103,7 @@ static void psr_flush_handler(unsigned long data)
return;
/* State changed between flush time, then keep it */
- if (psr->request_state != PSR_FLUSH)
+ if (psr->state != PSR_FLUSH)
return;
psr_set_state(psr, PSR_ENABLE);
@@ -183,7 +167,7 @@ void rockchip_drm_psr_flush(struct drm_device *dev)
spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
- if (psr->request_state == PSR_DISABLE)
+ if (psr->state == PSR_DISABLE)
continue;
mod_timer(&psr->flush_timer,
@@ -219,8 +203,6 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
setup_timer(&psr->flush_timer, psr_flush_handler, (unsigned long)psr);
- INIT_DELAYED_WORK(&psr->state_work, psr_state_work);
-
psr->state = PSR_DISABLE;
psr->encoder = encoder;
psr->set = psr_set;
--
2.8.0.rc3.226.g39d4020
[PATCH v2 1/6] drm/rockchip: Convert psr_list_mutex to spinlock and use it
This patch converts the psr_list_mutex to a spinlock and locks
all access to psr_list to avoid races (however unlikely they
were).
Signed-off-by: Sean Paul
---
Changes in v2:
- Rebased on
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 25 ++---
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b43fe5d9..76eaf1d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -157,7 +157,7 @@ static int rockchip_drm_bind(struct device *dev)
drm_dev->dev_private = private;
INIT_LIST_HEAD(&private->psr_list);
- mutex_init(&private->psr_list_mutex);
+ spin_lock_init(&private->psr_list_lock);
drm_mode_config_init(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 9c34c9e..5c69845 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -63,7 +63,7 @@ struct rockchip_drm_private {
struct drm_atomic_state *state;
struct list_head psr_list;
- struct mutex psr_list_mutex;
+ spinlock_t psr_list_lock;
};
int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a6d3bd25..bd25273 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -45,12 +45,18 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc
*crtc)
{
struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
struct psr_drv *psr;
+ unsigned long flags;
- list_for_each_entry(psr, &drm_drv->psr_list, list)
+ spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+ list_for_each_entry(psr, &drm_drv->psr_list, list) {
if (psr->encoder->crtc == crtc)
- return psr;
+ goto out;
+ }
+ psr = ERR_PTR(-ENODEV);
- return ERR_PTR(-ENODEV);
+out:
+ spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+ return psr;
}
static void psr_state_work(struct work_struct *work)
@@ -173,7 +179,9 @@ void rockchip_drm_psr_flush(struct drm_device *dev)
{
struct rockchip_drm_private *drm_drv = dev->dev_private;
struct psr_drv *psr;
+ unsigned long flags;
+ spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
if (psr->request_state == PSR_DISABLE)
continue;
@@ -183,6 +191,7 @@ void rockchip_drm_psr_flush(struct drm_device *dev)
psr_set_state(psr, PSR_FLUSH);
}
+ spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
}
EXPORT_SYMBOL(rockchip_drm_psr_flush);
@@ -199,6 +208,7 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
{
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr;
+ unsigned long flags;
if (!encoder || !psr_set)
return -EINVAL;
@@ -215,9 +225,9 @@ int rockchip_drm_psr_register(struct drm_encoder *encoder,
psr->encoder = encoder;
psr->set = psr_set;
- mutex_lock(&drm_drv->psr_list_mutex);
+ spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
list_add_tail(&psr->list, &drm_drv->psr_list);
- mutex_unlock(&drm_drv->psr_list_mutex);
+ spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
return 0;
}
@@ -235,8 +245,9 @@ void rockchip_drm_psr_unregister(struct drm_encoder
*encoder)
{
struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
struct psr_drv *psr, *n;
+ unsigned long flags;
- mutex_lock(&drm_drv->psr_list_mutex);
+ spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
list_for_each_entry_safe(psr, n, &drm_drv->psr_list, list) {
if (psr->encoder == encoder) {
del_timer(&psr->flush_timer);
@@ -244,6 +255,6 @@ void rockchip_drm_psr_unregister(struct drm_encoder
*encoder)
kfree(psr);
}
}
- mutex_unlock(&drm_drv->psr_list_mutex);
+ spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
}
EXPORT_SYMBOL(rockchip_drm_psr_unregister);
--
2.8.0.rc3.226.g39d4020
[PATCH v2 0/6] drm/rockchip: Some patches to update the PSR series
This is a follow-on set to Yakir's original PSR set here: https://lkml.org/lkml/2016/7/24/34 and applies to the for-next branch at: https://cgit.freedesktop.org/~seanpaul/dogwood There are a few issues with the code that needed to be shored up. (1) The use of mutexes instead of spinlocks caused issues calling the psr functions from vblank_enable/disable. (2) The proliferation of workers due to (1) (3) A bunch of races due to (2) (4) vblank is not enabled unless an event is requested, this breaks a lot of things, but most noticeable was cursor. Changes in v2: - Rebased on https://cgit.freedesktop.org/~seanpaul/dogwood instead of random on-list patches (some of which had drifted) - Added the "small fixes" patch to catch some nits Sean Paul (6): drm/rockchip: Convert psr_list_mutex to spinlock and use it drm/rockchip: Don't use a delayed worker for psr state changes drm/rockchip: Use a spinlock to protect psr state drm/rockchip: A couple small fixes to psr drm/rockchip: Improve analogix-dp psr handling drm/rockchip: Enable vblank without event drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 -- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 90 - drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++-- 5 files changed, 69 insertions(+), 59 deletions(-) -- 2.8.0.rc3.226.g39d4020
[Bug 97369] AMDGPU/Iceland hangs kernel 4.8-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=97369 --- Comment #1 from Alex Deucher --- You need this patch: https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=c39b487f195b93235ee76384427467786f7bf29f -- 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/20160816/f675a468/attachment.html>
[Bug 97369] AMDGPU/Iceland hangs kernel 4.8-rc2
ded Aug 16 19:49:49 krejzi kernel: [drm] ib test on ring 8 succeeded Aug 16 19:49:49 krejzi kernel: [drm:sdma_v2_4_ring_test_ib [amdgpu]] *ERROR* amdgpu: fence wait failed (1000). Aug 16 19:49:49 krejzi kernel: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on ring 9 (1000). Aug 16 19:49:49 krejzi kernel: [drm:sdma_v2_4_ring_test_ib [amdgpu]] *ERROR* amdgpu: fence wait failed (1000). Aug 16 19:49:49 krejzi kernel: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on ring 10 (1000). Aug 16 19:49:49 krejzi kernel: [drm] Initialized amdgpu 3.3.0 20150101 for :01:00.0 on minor 1 Radeon R7 M340 Hybrid Graphics, Topaz/Iceland. -- 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/20160816/0dc45442/attachment-0001.html>
[PATCH v4] drm: Introduce DRM_DEV_* log messages
On Tue, Aug 16, 2016 at 09:18:34AM -0700, Sean Paul wrote:
> On Tue, Aug 16, 2016 at 5:28 AM, Eric Engestrom
> wrote:
> > On Mon, Aug 15, 2016 at 04:18:04PM -0700, Sean Paul wrote:
> >> This patch consolidates all the various log functions/macros into
> >> one uber function, drm_log. It also introduces some new DRM_DEV_*
> >> variants that print the device name to delineate multiple devices
> >> of the same type.
> >>
> >> Signed-off-by: Sean Paul
> >> ---
> >>
> >> Changes in v2:
> >> - Use dev_printk for the dev variant (Chris Wilson)
> >>
> >> Changes in v3:
> >> - Rename drm_log to drm_dev_printk (Chris Wilson)
> >> - Break out drm_printk from drm_dev_printk to reduce
> >> image growth due to passing NULL around (Chris Wilson)
> >>
> >> Changes in v4:
> >> - Pull format string out into #define (Eric Engestrom)
> >>
> >>
> >> drivers/gpu/drm/drm_drv.c | 27 ++---
> >> include/drm/drmP.h| 140
> >> +++---
> >> 2 files changed, 103 insertions(+), 64 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index 57ce973..a7f6282 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -63,37 +63,48 @@ static struct idr drm_minors_idr;
> >>
> >> static struct dentry *drm_debugfs_root;
> >>
> >> -void drm_err(const char *format, ...)
> >> +#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> >> +
> >> +void drm_dev_printk(const struct device *dev, const char *level,
> >> + unsigned int category, const char *function_name,
> >> + const char *prefix, const char *format, ...)
> >> {
> >> struct va_format vaf;
> >> va_list args;
> >>
> >> - va_start(args, format);
> >> + if (category != DRM_UT_NONE && !(drm_debug & category))
> >> + return;
> >>
> >> + va_start(args, format);
> >> vaf.fmt = format;
> >> vaf.va = &args;
> >>
> >> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> >> -__builtin_return_address(0), &vaf);
> >> + dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
> >> +&vaf);
> >>
> >> va_end(args);
> >> }
> >> -EXPORT_SYMBOL(drm_err);
> >> +EXPORT_SYMBOL(drm_dev_printk);
> >>
> >> -void drm_ut_debug_printk(const char *function_name, const char *format,
> >> ...)
> >> +void drm_printk(const char *level, unsigned int category,
> >> + const char *function_name, const char *prefix,
> >> + const char *format, ...)
> >> {
> >> struct va_format vaf;
> >> va_list args;
> >>
> >> + if (category != DRM_UT_NONE && !(drm_debug & category))
> >> + return;
> >> +
> >> va_start(args, format);
> >> vaf.fmt = format;
> >> vaf.va = &args;
> >>
> >> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
> >> + printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
> >>
> >> va_end(args);
> >> }
> >> -EXPORT_SYMBOL(drm_ut_debug_printk);
> >> +EXPORT_SYMBOL(drm_printk);
> >>
> >> /*
> >> * DRM Minors
> >> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> >> index f8e87fd..94eb138 100644
> >> --- a/include/drm/drmP.h
> >> +++ b/include/drm/drmP.h
> >> @@ -127,6 +127,7 @@ struct dma_buf_attachment;
> >> * run-time by echoing the debug value in its sysfs node:
> >> * # echo 0xf > /sys/module/drm/parameters/debug
> >> */
> >> +#define DRM_UT_NONE 0x00
> >> #define DRM_UT_CORE 0x01
> >> #define DRM_UT_DRIVER0x02
> >> #define DRM_UT_KMS 0x04
> >> @@ -134,11 +135,15 @@ struct dma_buf_attachment;
> >> #define DRM_UT_ATOMIC0x10
> >> #define DRM_UT_VBL 0x20
> >>
> >> -extern __printf(2, 3)
> >> -void drm_ut_debug_printk(const char *function_name,
> >> - const char *format, ...);
> >> -extern __printf(1, 2)
> >> -void drm_err(const char *format, ...);
> >> +extern __printf(6, 7)
> >> +void drm_dev_printk(const struct device *dev, const char *level,
> >> + unsigned int category, const char *function_name,
> >> + const char *prefix, const char *format, ...);
> >> +
> >> +extern __printf(5, 6)
> >> +void drm_printk(const char *level, unsigned int category,
> >> + const char *function_name, const char *prefix,
> >> + const char *format, ...);
> >>
> >> /***/
> >> /** \name DRM template customization defaults */
> >> @@ -169,8 +174,12 @@ void drm_err(const char *format, ...);
> >> * \param fmt printf() like format string.
> >> * \param arg arguments
> >> */
> >> -#define DRM_ERROR(fmt, ...) \
> >> - drm_err(fmt, ##__VA_ARGS__)
> >> +#define DRM_DEV_ERROR(dev, fmt, ...) \
> >> + drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func_
[PATCH V2] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
On Tue, Aug 16, 2016 at 03:34:37PM +0200, Lothar WaÃmann wrote:
> Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in
> the kerneldoc comments and add kerneldoc comments to the new function
> drm_bus_flags_from_videomode().
>
> Signed-off-by: Lothar WaÃmann
Applied to drm-misc, thanks.
-Daniel
> ---
> Changes vs. v1:
> - added missing characters
>
> drivers/gpu/drm/drm_modes.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 1570487..53f07ac 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct
> drm_display_mode *dmode,
> }
> EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
>
> +/**
> + * drm_bus_flags_from_videomode - extract information about pixelclk and
> + * DE polarity from videomode and store it in a separate variable
> + * @vm: videomode structure to use
> + * @bus_flags: information about pixelclk and DE polarity will be stored here
> + *
> + * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
> + * in @bus_flags according to DISPLAY_FLAGS found in @vm
> + */
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
> {
> *bus_flags = 0;
> @@ -677,6 +686,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
> * of_get_drm_display_mode - get a drm_display_mode from devicetree
> * @np: device_node with the timing specification
> * @dmode: will be set to the return value
> + * @bus_flags: information about pixelclk and DE polarity
> * @index: index into the list of display timings in devicetree
> *
> * This function is expensive and should only be used, if only one mode is
> to be
> --
> 2.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 2/3] drm: simpledrm: add fbdev fallback support
On Tue, Aug 16, 2016 at 03:10:06PM +0200, Noralf Trønnes wrote:
>
> Den 15.08.2016 08:48, skrev Daniel Vetter:
> > On Sun, Aug 14, 2016 at 06:52:05PM +0200, Noralf Trønnes wrote:
> > > Create a simple fbdev device during SimpleDRM setup so legacy user-space
> > > and fbcon can use it.
> > >
> > > Original work by David Herrmann.
> > >
> > > Cc: dh.herrmann at gmail.com
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > >
> > > Changes from version 2:
> > > - Switch to using drm_fb_helper in preparation for future panic handling
> > >which needs an enabled pipeline.
> > >
> > > Changes from version 1:
> > >No changes
> > >
> > > Changes from previous version:
> > > - Remove the DRM_SIMPLEDRM_FBDEV kconfig option and use
> > > DRM_FBDEV_EMULATION
> > > - Suspend fbcon/fbdev when the pipeline is enabled, resume in lastclose
> > > - Add FBINFO_CAN_FORCE_OUTPUT flag so we get oops'es on the console
> > >
> > > drivers/gpu/drm/simpledrm/Kconfig | 3 +
> > > drivers/gpu/drm/simpledrm/Makefile | 1 +
> > > drivers/gpu/drm/simpledrm/simpledrm.h | 32 -
> > > drivers/gpu/drm/simpledrm/simpledrm_drv.c | 4 +
> > > drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 201
> > >
> > > drivers/gpu/drm/simpledrm/simpledrm_kms.c | 10 +-
> > > 6 files changed, 249 insertions(+), 2 deletions(-)
> > > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> > >
> > > diff --git a/drivers/gpu/drm/simpledrm/Kconfig
> > > b/drivers/gpu/drm/simpledrm/Kconfig
> > > index f45b25d..9454536 100644
> > > --- a/drivers/gpu/drm/simpledrm/Kconfig
> > > +++ b/drivers/gpu/drm/simpledrm/Kconfig
> > > @@ -13,6 +13,9 @@ config DRM_SIMPLEDRM
> > > SimpleDRM supports "simple-framebuffer" DeviceTree objects and
> > > compatible platform framebuffers.
> > >
> > > + If fbdev support is enabled, this driver will also provide an fbdev
> > > + compatibility layer.
> > > +
> > > If unsure, say Y.
> > >
> > > To compile this driver as a module, choose M here: the
> > > diff --git a/drivers/gpu/drm/simpledrm/Makefile
> > > b/drivers/gpu/drm/simpledrm/Makefile
> > > index f6a62dc..7087245 100644
> > > --- a/drivers/gpu/drm/simpledrm/Makefile
> > > +++ b/drivers/gpu/drm/simpledrm/Makefile
> > > @@ -1,4 +1,5 @@
> > > simpledrm-y := simpledrm_drv.o simpledrm_kms.o simpledrm_gem.o \
> > > simpledrm_damage.o
> > > +simpledrm-$(CONFIG_DRM_FBDEV_EMULATION) += simpledrm_fbdev.o
> > >
> > > obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
> > > diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
> > > b/drivers/gpu/drm/simpledrm/simpledrm.h
> > > index 481acc2..f01b75d 100644
> > > --- a/drivers/gpu/drm/simpledrm/simpledrm.h
> > > +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
> > > @@ -17,13 +17,13 @@
> > >
> > > struct simplefb_format;
> > > struct regulator;
> > > -struct fb_info;
> > > struct clk;
> > >
> > > struct sdrm_device {
> > > struct drm_device *ddev;
> > > struct drm_simple_display_pipe pipe;
> > > struct drm_connector conn;
> > > + struct sdrm_fbdev *fbdev;
> > >
> > > /* framebuffer information */
> > > const struct simplefb_format *fb_sformat;
> > > @@ -46,6 +46,7 @@ struct sdrm_device {
> > > #endif
> > > };
> > >
> > > +void sdrm_lastclose(struct drm_device *ddev);
> > > int sdrm_drm_modeset_init(struct sdrm_device *sdrm);
> > > int sdrm_drm_mmap(struct file *filp, struct vm_area_struct *vma);
> > >
> > > @@ -87,4 +88,33 @@ struct sdrm_framebuffer {
> > >
> > > #define to_sdrm_fb(x) container_of(x, struct sdrm_framebuffer, base)
> > >
> > > +#ifdef CONFIG_DRM_FBDEV_EMULATION
> > > +
> > > +void sdrm_fbdev_init(struct sdrm_device *sdrm);
> > > +void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
> > > +void sdrm_fbdev_display_pipe_update(struct sdrm_device *sdrm,
> > > + struct drm_framebuffer *fb);
> > > +void sdrm_fbdev_restore_mode(struct sdrm_device *sdrm);
> > > +
> > > +#else
> > > +
> > > +static inline void sdrm_fbdev_init(struct sdrm_device *sdrm)
> > > +{
> > > +}
> > > +
> > > +static inline void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
> > > +{
> > > +}
> > > +
> > > +static inline void sdrm_fbdev_display_pipe_update(struct sdrm_device
> > > *sdrm,
> > > + struct drm_framebuffer *fb)
> > > +{
> > > +}
> > > +
> > > +static inline void sdrm_fbdev_restore_mode(struct sdrm_device *sdrm)
> > > +{
> > > +}
> > > +
> > > +#endif
> > Why do we need the #ifdefs here? Imo those few bytes of codes we can save
> > aren't worth the complexity ...
>
> This one is needed to make fbdev optional, which I assume is what we want?
> Actually I can drop sdrm_fbdev_display_pipe_update() and
> sdrm_fbdev_restore_mode() if I use drm_fb_helper_set_suspend() as you
> remineded me of further down.
>
> Or do you actually refer to the #ifdef
[PATCH v3 1/3] drm: add SimpleDRM driver
On Tue, Aug 16, 2016 at 02:58:38PM +0200, Noralf Trønnes wrote:
>
> Den 15.08.2016 08:59, skrev Daniel Vetter:
> > On Sun, Aug 14, 2016 at 06:52:04PM +0200, Noralf Trønnes wrote:
> > > The SimpleDRM driver binds to simple-framebuffer devices and provides a
> > > DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> > > plus one initial mode.
> > >
> > > Userspace can create dumb-buffers which can be blit into the real
> > > framebuffer similar to UDL. No access to the real framebuffer is allowed
> > > (compared to earlier version of this driver) to avoid security issues.
> > > Furthermore, this way we can support arbitrary modes as long as we have a
> > > conversion-helper.
> > >
> > > The driver was originally written by David Herrmann in 2014.
> > > My main contribution is to make use of drm_simple_kms_helper and
> > > rework the probe path to avoid use of the deprecated drm_platform_init()
> > > and drm_driver.{load,unload}().
> > > Additions have also been made for later changes to the Device Tree binding
> > > document, like support for clocks, regulators and having the node under
> > > /chosen. This code was lifted verbatim from simplefb.c.
> > >
> > > Cc: dh.herrmann at gmail.com
> > > Cc: libv at skynet.be
> > > Signed-off-by: Noralf Trønnes
>
>
>
> > > diff --git a/drivers/gpu/drm/simpledrm/simpledrm_gem.c
> > > b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
> > > new file mode 100644
> > > index 000..81bd7c5
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
>
>
>
> > > +struct sdrm_gem_object *sdrm_gem_alloc_object(struct drm_device *ddev,
> > > + size_t size)
> > > +{
> > > + struct sdrm_gem_object *obj;
> > > +
> > > + WARN_ON(!size || (size & ~PAGE_MASK) != 0);
> > > +
> > > + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> > > + if (!obj)
> > > + return NULL;
> > > +
> > > + drm_gem_private_object_init(ddev, &obj->base, size);
> > > + return obj;
> > > +}
> > > +
> > > +void sdrm_gem_free_object(struct drm_gem_object *gobj)
> > > +{
> > > + struct sdrm_gem_object *obj = to_sdrm_bo(gobj);
> > > + struct drm_device *ddev = gobj->dev;
> > > +
> > > + if (obj->pages) {
> > > + /* kill all user-space mappings */
> > > + drm_vma_node_unmap(&gobj->vma_node,
> > > +ddev->anon_inode->i_mapping);
> > > + sdrm_gem_put_pages(obj);
> > > + }
> > > +
> > > + if (gobj->import_attach)
> > > + drm_prime_gem_destroy(gobj, obj->sg);
> > > +
> > > + drm_gem_free_mmap_offset(gobj);
> > > + drm_gem_object_release(gobj);
> > > + kfree(obj);
> > > +}
> > > +
> > > +int sdrm_dumb_create(struct drm_file *dfile, struct drm_device *ddev,
> > > + struct drm_mode_create_dumb *args)
> > > +{
> > > + struct sdrm_gem_object *obj;
> > > + int r;
> > > +
> > > + if (args->flags)
> > > + return -EINVAL;
> > > +
> > > + /* overflow checks are done by DRM core */
> > > + args->pitch = (args->bpp + 7) / 8 * args->width;
> > > + args->size = PAGE_ALIGN(args->pitch * args->height);
> > > +
> > > + obj = sdrm_gem_alloc_object(ddev, args->size);
> > > + if (!obj)
> > > + return -ENOMEM;
> > > +
> > > + r = drm_gem_handle_create(dfile, &obj->base, &args->handle);
> > > + if (r) {
> > > + drm_gem_object_unreference_unlocked(&obj->base);
> > > + return r;
> > > + }
> > > +
> > > + /* handle owns a reference */
> > > + drm_gem_object_unreference_unlocked(&obj->base);
> > > + return 0;
> > > +}
> > > +
> > > +int sdrm_dumb_destroy(struct drm_file *dfile, struct drm_device *ddev,
> > > + uint32_t handle)
> > > +{
> > > + return drm_gem_handle_delete(dfile, handle);
> > > +}
> > I wonder whether some dumb+gem helpers wouldn't be useful to roll out. At
> > least drm_dumb_gem_destroy.c would be pretty simple.
>
> There's already a drm_gem_dumb_destroy() in drm_gem.c
>
> The drm_driver->gem_create_object callback makes it possible to do a
> generic dumb create:
>
> int drm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args)
> {
> struct drm_gem_object *obj;
> int ret;
>
> if (!dev->driver->gem_create_object)
> return -EINVAL;
>
> args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> args->size = args->pitch * args->height;
>
> obj = dev->driver->gem_create_object(dev, args->size);
> if (!obj)
> return -ENOMEM;
>
> ret = drm_gem_handle_create(file, obj, &args->handle);
> drm_gem_object_unreference_unlocked(obj);
>
> return ret;
> }
> EXPORT_SYMBOL(drm_gem_dumb_create);
>
> struct drm_gem_object *sdrm_gem_create_object(struct drm_device *ddev,
> size_t size)
> {
> struct sdrm_gem_object *sobj;
>
> sobj = sdrm_gem_alloc_object(ddev, size);
> if (!sobj)
> return ERR_PTR(-ENOMEM);
>
> return &sobj->base;
> }
>
> > > +
> > > +int sdrm_dumb_map_offset(str
[PATCH V4 2/4] Documentation/devicetree/bindings: b850v3_lvds_dp
On 04/08/16 23:36, Peter Senna Tschudin wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Javier Martinez Canillas
> Cc: Enric Balletbo i Serra
> Cc: Philipp Zabel
> Cc: Rob Herring
> Cc: Fabio Estevam
> Signed-off-by: Peter Senna Tschudin
Acked-by: Martyn Welch
> ---
> Changes from V3:
> - 2/4 instead of 3/5
>
> Unchanged from V2
>
> Changes from V1:
> - Replaced '_' by '-' in node names or compatible strings
> - Added missing @73 to the example
>
> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 37
> ++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 000..f05c3e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,37 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> + - compatible : should be "ge,b850v3-lvds-dp".
> + - reg : should contain the address used to ack the interrupts.
> + - interrupt-parent : phandle of the interrupt controller that services
> +interrupts to the device
> + - interrupts : one interrupt should be described here, as in
> +<0 IRQ_TYPE_LEVEL_HIGH>.
> + - edid-reg : should contain the address used to read edid information
> + - port : should describe the video signal connection between the host
> +and the bridge.
> +
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <10>;
> +
> + b850v3-lvds-dp-bridge at 73 {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + edid-reg = <0x72>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
>
[PATCH V4 1/4] drm/imx-ldb: Add support to drm-bridge
On 04/08/16 23:36, Peter Senna Tschudin wrote:
> Add support to attach a drm_bridge to imx-ldb in addition to
> existing support to attach a LVDS panel.
>
> This patch does a simple code refactoring by moving code
> from for_each_child_of_node iterator to a new function named
> imx_ldb_panel_ddc(). This was necessary to allow the panel ddc
> code to run only when the imx_ldb is not attached to a bridge.
>
> Cc: Enric Balletbo i Serra
> Cc: Philipp Zabel
> Cc: Rob Herring
> Cc: Fabio Estevam
> Cc: David Airlie
> Cc: Thierry Reding
> Cc: Thierry Reding
> Signed-off-by: Peter Senna Tschudin
Acked-by: Martyn Welch
> ---
> Changes from V3:
> - The connector is created when there is no bridge instead of only when
>there is a pannel
> - Tested on next-20160804
>
> Changes from V2:
> - Updated to be aplied on top of Liu Ying changes that made imx-ldb atomic
> - Tested on next-20160729
>
> Changes from V1:
> - Reanmed ext_bridge to bridge
> - Removed empty entry point imx_ldb_encoder_enable()
> - Adapted the code to apply to the latest linux next: next-20160609
>
> drivers/gpu/drm/imx/imx-ldb.c | 118
> --
> 1 file changed, 78 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
> index b03919e..4a33077 100644
> --- a/drivers/gpu/drm/imx/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/imx-ldb.c
> @@ -57,7 +57,11 @@ struct imx_ldb_channel {
> struct imx_ldb *ldb;
> struct drm_connector connector;
> struct drm_encoder encoder;
> +
> + /* Defines what is connected to the ldb, only one at a time */
> struct drm_panel *panel;
> + struct drm_bridge *bridge;
> +
> struct device_node *child;
> struct i2c_adapter *ddc;
> int chno;
> @@ -466,10 +470,30 @@ static int imx_ldb_register(struct drm_device *drm,
> drm_encoder_init(drm, encoder, &imx_ldb_encoder_funcs,
>DRM_MODE_ENCODER_LVDS, NULL);
>
> - drm_connector_helper_add(&imx_ldb_ch->connector,
> - &imx_ldb_connector_helper_funcs);
> - drm_connector_init(drm, &imx_ldb_ch->connector,
> -&imx_ldb_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
> + if (imx_ldb_ch->bridge) {
> + imx_ldb_ch->bridge->encoder = encoder;
> +
> + imx_ldb_ch->encoder.bridge = imx_ldb_ch->bridge;
> + ret = drm_bridge_attach(drm, imx_ldb_ch->bridge);
> + if (ret) {
> + DRM_ERROR("Failed to initialize bridge with drm\n");
> + return ret;
> + }
> + } else {
> + /*
> + * We want to add the connector whenever there is no bridge
> + * that brings its own, not only when there is a panel. For
> + * historical reasons, the ldb driver can also work without
> + * a panel.
> + */
> + drm_connector_helper_add(&imx_ldb_ch->connector,
> + &imx_ldb_connector_helper_funcs);
> + drm_connector_init(drm, &imx_ldb_ch->connector,
> + &imx_ldb_connector_funcs,
> + DRM_MODE_CONNECTOR_LVDS);
> + drm_mode_connector_attach_encoder(&imx_ldb_ch->connector,
> + encoder);
> + }
>
> if (imx_ldb_ch->panel) {
> ret = drm_panel_attach(imx_ldb_ch->panel,
> @@ -478,8 +502,6 @@ static int imx_ldb_register(struct drm_device *drm,
> return ret;
> }
>
> - drm_mode_connector_attach_encoder(&imx_ldb_ch->connector, encoder);
> -
> return 0;
> }
>
> @@ -548,6 +570,45 @@ static const struct of_device_id imx_ldb_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, imx_ldb_dt_ids);
>
> +static int imx_ldb_panel_ddc(struct device *dev,
> + struct imx_ldb_channel *channel, struct device_node *child)
> +{
> + struct device_node *ddc_node;
> + const u8 *edidp;
> + int ret;
> +
> + ddc_node = of_parse_phandle(child, "ddc-i2c-bus", 0);
> + if (ddc_node) {
> + channel->ddc = of_find_i2c_adapter_by_node(ddc_node);
> + of_node_put(ddc_node);
> + if (!channel->ddc) {
> + dev_warn(dev, "failed to get ddc i2c adapter\n");
> + return -EPROBE_DEFER;
> + }
> + }
> +
> + if (!channel->ddc) {
> + /* if no DDC available, fallback to hardcoded EDID */
> + dev_dbg(dev, "no ddc available\n");
> +
> + edidp = of_get_property(child, "edid",
> + &channel->edid_len);
> + if (edidp) {
> + channel->edid = kmemdup(edidp,
> + channel->edid_len,
> + GFP_KERNEL);
> + } else if (!channel->panel) {
> + /* fallback to
[PATCH] dma-buf: fix kernel-doc warning and typos
From: Randy Dunlap Fix dma-buf kernel-doc warning and 2 minor typos in fence_array_create(). Fixes this warning: ..//drivers/dma-buf/fence-array.c:124: warning: No description found for parameter 'signal_on_any' Signed-off-by: Randy Dunlap Cc: Sumit Semwal Cc: linux-media at vger.kernel.org Cc: dri-devel at lists.freedesktop.org Cc: linaro-mm-sig at lists.linaro.org --- drivers/dma-buf/fence-array.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c +++ lnx-48-rc2/drivers/dma-buf/fence-array.c @@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops = * @fences:[in]array containing the fences * @context: [in]fence context to use * @seqno: [in]sequence number to use - * @signal_on_any [in]signal on any fence in the array + * @signal_on_any: [in]signal on any fence in the array * * Allocate a fence_array object and initialize the base fence with fence_init(). * In case of error it returns NULL. * - * The caller should allocte the fences array with num_fences size + * The caller should allocate the fences array with num_fences size * and fill it with the fences it wants to add to the object. Ownership of this - * array is take and fence_put() is used on each fence on release. + * array is taken and fence_put() is used on each fence on release. * * If @signal_on_any is true the fence array signals if any fence in the array * signals, otherwise it signals when all fences in the array signal.
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On 16/08/16 04:00 PM, Deng, Emily wrote: >> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of >> Michel D?nzer >> Sent: Tuesday, August 16, 2016 2:43 PM >> On 16/08/16 03:28 PM, Deng, Emily wrote: From: Michel Dänzer [mailto:michel at daenzer.net] Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, Deng, Emily wrote: > Hi Michel, Thanks, I still couldn't see the issue that use a > variable to calculate the vblank count when vsync timer interrupt > occurs. I just think it only emulates the hardware behavior. And the > code change will only in virtual display files which won't touch drm > layer. I incline to not modify the code in drm layer or amdgpu other > codes, because it may lead to other issues . I see it basically the other way around: We are currently pretending to the DRM core code that we have a reliable hardware vblank counter and timing even in the virtual DCE case, when we really don't. We should stop pretending and instead communicate the lack of these hardware facilities in the virtual DCE case as intended, otherwise we'll >> probably run into issues sooner or later. >>> [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware >>> vblank counter in virtual DCE case to drm layer. But can you specific some >> cases that we must communicate with drm layer that we don't have the vblank >> counter. >> >> I described all the necessary steps (that I know of; there may be more) in >> https://lists.freedesktop.org/archives/amd-gfx/2016-August/001342.html . >> > [[EmilyD]] Hi Michel, I means can you detail the reasons or cases that we > should communicate with drm layer > when don't have the vblank counter instead of pretending a hardware vblank > counter in virtual DCE case. The DRM core code expects the get_vblank_counter hook to use a reliable hardware counter. If that is not the case, it should always return 0. Similarly, drm_calc_vbltimestamp_from_scanoutpos expects the get_scanout_position hook to return accurate scanout position values based on reliable hardware registers. If we pretend to return accurate values from these when we actually can't, the DRM core code may provide incorrect vblank counter / timestamp values to userspace, or worse. Those are just off the top of my head, there may be more along the same lines. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 97099] Regression in 9ef8537e6 "drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled" (RV620)
https://bugs.freedesktop.org/show_bug.cgi?id=97099 --- Comment #5 from Jaime Velasco Juan --- Thanks, the patch fixes the problem for me, as expected. I hope it doesn't break other setups. I understand having to lose time with these kind of workarounds must be very frustrating. -- 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/20160816/e0e9001d/attachment.html>
[PATCH v3 01/11] drm/i915: Add i915 perf infrastructure
On Tue, Aug 16, 2016 at 03:59:24PM +0100, Robert Bragg wrote: >On Mon, Aug 15, 2016 at 3:57 PM, Chris Wilson > Alternatively you could follow the standard pattern for read. Dare I ask > what is going to go into state that needs the obfuscation? > >I had dug around a bit when I was trying to decide how to handle the >corner cases here and found some precedent for prioritize reporting any >data copied over an error for a read(). Reporting completed bytes before the error is correct. I was referring to going between passing the return value as a mixture of state and return, when it just appears to be following the usual pattern of read(). i.e. I could find anything to support why your internal read callback required a different signature. It looks unusual, so I am expecting it to do unusual things. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v3 01/11] drm/i915: Add i915 perf infrastructure
interesting if we weren't able to copy some data * because it implies the userspace buffer is too small to * receive a single record (and we never split records). * * Another case with ret == -EFAULT is more of a grey area * since it would seem like bad form for userspace to ask us * to overrun its buffer, but the user knows best: * * http://yarchive.net/comp/linux/partial_reads_writes.html */ return state.read ?: (ret ?: -EAGAIN); Searching for another reference, I also just found the linux device drivers book talks about the same kind of convention: http://www.makelinux.net/ldd3/chp-3-sect-7 "Both the read and write methods return a negative value if an error occurs. A return value greater than or equal to 0, instead, tells the calling program how many bytes have been successfully transferred. If some data is transferred correctly and then an error happens, the return value must be the count of bytes successfully transferred, and the error does not get reported until the next time the function is called. Implementing this convention requires, of course, that your driver remember that the error has occurred so that it can return the error status in the future." - Robert > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160816/510e1aa5/attachment.html>
[Bug 97260] [bisected] R9 290 low performance in Linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #20 from Kai ---
Created attachment 125820
--> https://bugs.freedesktop.org/attachment.cgi?id=125820&action=edit
dmesg output with additional debug info from attachment 125808
(In reply to Alex Deucher from comment #16)
> Does just reverting this chunk fix the issue?
>
> @@ -1630,6 +1631,9 @@ int radeon_modeset_init(struct radeon_device *rdev)
>
> rdev->ddev->mode_config.funcs = &radeon_mode_funcs;
>
> + if (radeon_use_pflipirq == 2 && rdev->family >= CHIP_R600)
> + rdev->ddev->mode_config.async_page_flip = true;
> +
> if (ASIC_IS_DCE5(rdev)) {
> rdev->ddev->mode_config.max_width = 16384;
> rdev->ddev->mode_config.max_height = 16384;
Yes, just removing the default enable here has the same effect as reverting the
entire patch.
(In reply to Michel Dänzer from comment #18)
> Created attachment 125808
> radeon: Add some page flip debugging output
>
> Well, that's a surprising result of the bisection.
>
> I can imagine two possible causes, or possibly some combination thereof:
>
> * The processing of asynchronous flips or the corresponding completion
> interrupts
> is delayed for some reason
> * Using flips instead of blits for buffer swaps lowers the load on the GPU 3D
> engine, so the SMU doesn't switch to higher clocks
>
> The attached debugging patch should give us more information about the
> former. With it applied, run the following while an affected application is
> running in fullscreen:
>
> sudo sh -c 'echo 2 >/sys/module/drm/parameters/debug'; sleep 1; sudo sh -c
> 'echo 0 >/sys/module/drm/parameters/debug'
>
> Then attach the resulting dmesg output.
Here you go. That was generated by running XCOM 2.
> BTW, does the problem still happen with Alex's current drm-next-4.9-wip
> branch?
Haven't tested that yet. Maybe somebody else can do that. ;-)
(In reply to Michel Dänzer from comment #19)
> BTW, there are some potential workarounds:
>
> * Disable DRI3 for affected games with the environment variable
> LIBGL_DRI3_DISABLE=1
>
> * Enable sync-to-vblank in affected applications, or force it with
> vblank_mode=3
Well, this is going to be odd: I had VSync enabled in XCOM, since without that
option I got poorer performance in the past than with it. Now, after your note
here I actually *disabled* the VSync option in the game. 4.6.4 (or 4.7.0
without the offending commit/the enable removed) shows no longer a performance
difference and I'm getting ~30 FPS in XCOM 2. BUT with your ASYNC patch
(vanilla 4.7.0) and VSync turned of in the game gives me ALSO ~30 FPS! I'd
still say this is a regression as there is no difference without your patch,
but maybe this information can help you in narrowing down the cause?
I hope I haven't missed any open question. Let me know if you need anything
else.
--
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/20160816/d6e250f6/attachment.html>
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On 16/08/16 03:28 PM, Deng, Emily wrote: >> From: Michel Dänzer [mailto:michel at daenzer.net] >> Sent: Tuesday, August 16, 2016 12:01 PM >> On 16/08/16 12:49 PM, Deng, Emily wrote: >>> Hi Michel, Thanks, I still couldn't see the issue that use a variable >>> to calculate the vblank count when vsync timer interrupt occurs. I >>> just think it only emulates the hardware behavior. And the code change >>> will only in virtual display files which won't touch drm layer. I >>> incline to not modify the code in drm layer or amdgpu other codes, >>> because it may lead to other issues . >> >> I see it basically the other way around: We are currently pretending to the >> DRM >> core code that we have a reliable hardware vblank counter and timing even in >> the virtual DCE case, when we really don't. We should stop pretending and >> instead communicate the lack of these hardware facilities in the virtual DCE >> case >> as intended, otherwise we'll probably run into issues sooner or later. >> > [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware vblank > counter in virtual DCE case to drm > layer. But can you specific some cases that we must communicate with drm > layer that we don't have the vblank counter. I described all the necessary steps (that I know of; there may be more) in https://lists.freedesktop.org/archives/amd-gfx/2016-August/001342.html . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH V2] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in
the kerneldoc comments and add kerneldoc comments to the new function
drm_bus_flags_from_videomode().
Signed-off-by: Lothar WaÃmann
---
Changes vs. v1:
- added missing characters
drivers/gpu/drm/drm_modes.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1570487..53f07ac 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct
drm_display_mode *dmode,
}
EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_bus_flags_from_videomode - extract information about pixelclk and
+ * DE polarity from videomode and store it in a separate variable
+ * @vm: videomode structure to use
+ * @bus_flags: information about pixelclk and DE polarity will be stored here
+ *
+ * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
+ * in @bus_flags according to DISPLAY_FLAGS found in @vm
+ */
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
{
*bus_flags = 0;
@@ -677,6 +686,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
* of_get_drm_display_mode - get a drm_display_mode from devicetree
* @np: device_node with the timing specification
* @dmode: will be set to the return value
+ * @bus_flags: information about pixelclk and DE polarity
* @index: index into the list of display timings in devicetree
*
* This function is expensive and should only be used, if only one mode is to
be
--
2.1.4
[PATCH] gpu: ipu-v3: fix a possible NULL dereference
of_match_device could return NULL, and so cause a NULL pointer
dereference later.
For fixing this problem, we use of_device_get_match_data(), this will
simplify the code a little by using a standard function for
getting the match data.
Signed-off-by: LABBE Corentin
---
drivers/gpu/ipu-v3/ipu-common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 99dcacf..05a9cc6 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1207,15 +1207,13 @@ EXPORT_SYMBOL_GPL(ipu_dump);
static int ipu_probe(struct platform_device *pdev)
{
- const struct of_device_id *of_id =
- of_match_device(imx_ipu_dt_ids, &pdev->dev);
struct ipu_soc *ipu;
struct resource *res;
unsigned long ipu_base;
int i, ret, irq_sync, irq_err;
const struct ipu_devtype *devtype;
- devtype = of_id->data;
+ devtype = of_device_get_match_data(&pdev->dev);
irq_sync = platform_get_irq(pdev, 0);
irq_err = platform_get_irq(pdev, 1);
--
2.7.3
[PATCH v3 2/3] drm: simpledrm: add fbdev fallback support
Den 15.08.2016 08:48, skrev Daniel Vetter:
> On Sun, Aug 14, 2016 at 06:52:05PM +0200, Noralf Trønnes wrote:
>> Create a simple fbdev device during SimpleDRM setup so legacy user-space
>> and fbcon can use it.
>>
>> Original work by David Herrmann.
>>
>> Cc: dh.herrmann at gmail.com
>> Signed-off-by: Noralf Trønnes
>> ---
>>
>> Changes from version 2:
>> - Switch to using drm_fb_helper in preparation for future panic handling
>>which needs an enabled pipeline.
>>
>> Changes from version 1:
>>No changes
>>
>> Changes from previous version:
>> - Remove the DRM_SIMPLEDRM_FBDEV kconfig option and use DRM_FBDEV_EMULATION
>> - Suspend fbcon/fbdev when the pipeline is enabled, resume in lastclose
>> - Add FBINFO_CAN_FORCE_OUTPUT flag so we get oops'es on the console
>>
>> drivers/gpu/drm/simpledrm/Kconfig | 3 +
>> drivers/gpu/drm/simpledrm/Makefile | 1 +
>> drivers/gpu/drm/simpledrm/simpledrm.h | 32 -
>> drivers/gpu/drm/simpledrm/simpledrm_drv.c | 4 +
>> drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 201
>>
>> drivers/gpu/drm/simpledrm/simpledrm_kms.c | 10 +-
>> 6 files changed, 249 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>>
>> diff --git a/drivers/gpu/drm/simpledrm/Kconfig
>> b/drivers/gpu/drm/simpledrm/Kconfig
>> index f45b25d..9454536 100644
>> --- a/drivers/gpu/drm/simpledrm/Kconfig
>> +++ b/drivers/gpu/drm/simpledrm/Kconfig
>> @@ -13,6 +13,9 @@ config DRM_SIMPLEDRM
>>SimpleDRM supports "simple-framebuffer" DeviceTree objects and
>>compatible platform framebuffers.
>>
>> + If fbdev support is enabled, this driver will also provide an fbdev
>> + compatibility layer.
>> +
>>If unsure, say Y.
>>
>>To compile this driver as a module, choose M here: the
>> diff --git a/drivers/gpu/drm/simpledrm/Makefile
>> b/drivers/gpu/drm/simpledrm/Makefile
>> index f6a62dc..7087245 100644
>> --- a/drivers/gpu/drm/simpledrm/Makefile
>> +++ b/drivers/gpu/drm/simpledrm/Makefile
>> @@ -1,4 +1,5 @@
>> simpledrm-y := simpledrm_drv.o simpledrm_kms.o simpledrm_gem.o \
>> simpledrm_damage.o
>> +simpledrm-$(CONFIG_DRM_FBDEV_EMULATION) += simpledrm_fbdev.o
>>
>> obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
>> b/drivers/gpu/drm/simpledrm/simpledrm.h
>> index 481acc2..f01b75d 100644
>> --- a/drivers/gpu/drm/simpledrm/simpledrm.h
>> +++ b/drivers/gpu/drm/simpledrm/simpledrm.h
>> @@ -17,13 +17,13 @@
>>
>> struct simplefb_format;
>> struct regulator;
>> -struct fb_info;
>> struct clk;
>>
>> struct sdrm_device {
>> struct drm_device *ddev;
>> struct drm_simple_display_pipe pipe;
>> struct drm_connector conn;
>> +struct sdrm_fbdev *fbdev;
>>
>> /* framebuffer information */
>> const struct simplefb_format *fb_sformat;
>> @@ -46,6 +46,7 @@ struct sdrm_device {
>> #endif
>> };
>>
>> +void sdrm_lastclose(struct drm_device *ddev);
>> int sdrm_drm_modeset_init(struct sdrm_device *sdrm);
>> int sdrm_drm_mmap(struct file *filp, struct vm_area_struct *vma);
>>
>> @@ -87,4 +88,33 @@ struct sdrm_framebuffer {
>>
>> #define to_sdrm_fb(x) container_of(x, struct sdrm_framebuffer, base)
>>
>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>> +
>> +void sdrm_fbdev_init(struct sdrm_device *sdrm);
>> +void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
>> +void sdrm_fbdev_display_pipe_update(struct sdrm_device *sdrm,
>> +struct drm_framebuffer *fb);
>> +void sdrm_fbdev_restore_mode(struct sdrm_device *sdrm);
>> +
>> +#else
>> +
>> +static inline void sdrm_fbdev_init(struct sdrm_device *sdrm)
>> +{
>> +}
>> +
>> +static inline void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
>> +{
>> +}
>> +
>> +static inline void sdrm_fbdev_display_pipe_update(struct sdrm_device *sdrm,
>> + struct drm_framebuffer *fb)
>> +{
>> +}
>> +
>> +static inline void sdrm_fbdev_restore_mode(struct sdrm_device *sdrm)
>> +{
>> +}
>> +
>> +#endif
> Why do we need the #ifdefs here? Imo those few bytes of codes we can save
> aren't worth the complexity ...
This one is needed to make fbdev optional, which I assume is what we want?
Actually I can drop sdrm_fbdev_display_pipe_update() and
sdrm_fbdev_restore_mode() if I use drm_fb_helper_set_suspend() as you
remineded me of further down.
Or do you actually refer to the #ifdef's around clk and regulator in
struct sdrm_device? I lifted that as-is from simplefb.c, but I wondered
if I shouldn't just have dropped them since it was only 2 pointers and
2 ints.
>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> new file mode 100644
>> index 000..4038dd9
>> --- /dev/null
>> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
>> @@ -0,0 +1,201 @@
>> +/*
>> + * SimpleDRM firmware framebuffer driver
>> + * Copyrigh
[PATCH v2] drm: drop DRIVER_HAVE_IRQ flag for some drivers
Since commit 4984979b9b90 ("drm/irq: simplify irq checks in
drm_wait_vblank"), the drm driver feature flag DRIVER_HAVE_IRQ is only
required for drivers that have an IRQ handler managed by the DRM core.
Some drivers, armada, etnaviv, kirin and sti, set this flag without
.irq_handler setup in drm_driver. These drivers manage IRQ handler
by themselves and the flag DRIVER_HAVE_IRQ makes no sense there.
Drop the flag for these drivers to avoid confusion.
Signed-off-by: Shawn Guo
Cc: Vincent Abriou
Cc: Xinliang Liu
Acked-by: Russell King (for armada and etnaviv)
---
Changes for v2:
- Improve commit log per Russell's suggestion
- Add Russell's ACK tag
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
drivers/gpu/drm/sti/sti_drv.c | 2 +-
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index f5ebdd681445..1e0e68f608e4 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -211,7 +211,7 @@ static struct drm_driver armada_drm_driver = {
.desc = "Armada SoC DRM",
.date = "20120730",
.driver_features= DRIVER_GEM | DRIVER_MODESET |
- DRIVER_HAVE_IRQ | DRIVER_PRIME,
+ DRIVER_PRIME,
.ioctls = armada_ioctls,
.fops = &armada_drm_fops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ffd1b32caa8d..fd0ed61565f3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -488,8 +488,7 @@ static const struct file_operations fops = {
};
static struct drm_driver etnaviv_drm_driver = {
- .driver_features= DRIVER_HAVE_IRQ |
- DRIVER_GEM |
+ .driver_features= DRIVER_GEM |
DRIVER_PRIME |
DRIVER_RENDER,
.open = etnaviv_open,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1edd9bc80294..1fc2f502d20d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -169,7 +169,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
+ DRIVER_ATOMIC,
.fops = &kirin_drm_fops,
.gem_free_object_unlocked = drm_gem_cma_free_object,
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 96bd3d08b2d4..f8311b2bc84e 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -282,7 +282,7 @@ static const struct file_operations sti_driver_fops = {
};
static struct drm_driver sti_driver = {
- .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
+ .driver_features = DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
--
1.9.1
[PATCH v3 1/3] drm: add SimpleDRM driver
Den 15.08.2016 08:59, skrev Daniel Vetter:
> On Sun, Aug 14, 2016 at 06:52:04PM +0200, Noralf Trønnes wrote:
>> The SimpleDRM driver binds to simple-framebuffer devices and provides a
>> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
>> plus one initial mode.
>>
>> Userspace can create dumb-buffers which can be blit into the real
>> framebuffer similar to UDL. No access to the real framebuffer is allowed
>> (compared to earlier version of this driver) to avoid security issues.
>> Furthermore, this way we can support arbitrary modes as long as we have a
>> conversion-helper.
>>
>> The driver was originally written by David Herrmann in 2014.
>> My main contribution is to make use of drm_simple_kms_helper and
>> rework the probe path to avoid use of the deprecated drm_platform_init()
>> and drm_driver.{load,unload}().
>> Additions have also been made for later changes to the Device Tree binding
>> document, like support for clocks, regulators and having the node under
>> /chosen. This code was lifted verbatim from simplefb.c.
>>
>> Cc: dh.herrmann at gmail.com
>> Cc: libv at skynet.be
>> Signed-off-by: Noralf Trønnes
>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_gem.c
>> b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
>> new file mode 100644
>> index 000..81bd7c5
>> --- /dev/null
>> +++ b/drivers/gpu/drm/simpledrm/simpledrm_gem.c
>> +struct sdrm_gem_object *sdrm_gem_alloc_object(struct drm_device *ddev,
>> + size_t size)
>> +{
>> +struct sdrm_gem_object *obj;
>> +
>> +WARN_ON(!size || (size & ~PAGE_MASK) != 0);
>> +
>> +obj = kzalloc(sizeof(*obj), GFP_KERNEL);
>> +if (!obj)
>> +return NULL;
>> +
>> +drm_gem_private_object_init(ddev, &obj->base, size);
>> +return obj;
>> +}
>> +
>> +void sdrm_gem_free_object(struct drm_gem_object *gobj)
>> +{
>> +struct sdrm_gem_object *obj = to_sdrm_bo(gobj);
>> +struct drm_device *ddev = gobj->dev;
>> +
>> +if (obj->pages) {
>> +/* kill all user-space mappings */
>> +drm_vma_node_unmap(&gobj->vma_node,
>> + ddev->anon_inode->i_mapping);
>> +sdrm_gem_put_pages(obj);
>> +}
>> +
>> +if (gobj->import_attach)
>> +drm_prime_gem_destroy(gobj, obj->sg);
>> +
>> +drm_gem_free_mmap_offset(gobj);
>> +drm_gem_object_release(gobj);
>> +kfree(obj);
>> +}
>> +
>> +int sdrm_dumb_create(struct drm_file *dfile, struct drm_device *ddev,
>> + struct drm_mode_create_dumb *args)
>> +{
>> +struct sdrm_gem_object *obj;
>> +int r;
>> +
>> +if (args->flags)
>> +return -EINVAL;
>> +
>> +/* overflow checks are done by DRM core */
>> +args->pitch = (args->bpp + 7) / 8 * args->width;
>> +args->size = PAGE_ALIGN(args->pitch * args->height);
>> +
>> +obj = sdrm_gem_alloc_object(ddev, args->size);
>> +if (!obj)
>> +return -ENOMEM;
>> +
>> +r = drm_gem_handle_create(dfile, &obj->base, &args->handle);
>> +if (r) {
>> +drm_gem_object_unreference_unlocked(&obj->base);
>> +return r;
>> +}
>> +
>> +/* handle owns a reference */
>> +drm_gem_object_unreference_unlocked(&obj->base);
>> +return 0;
>> +}
>> +
>> +int sdrm_dumb_destroy(struct drm_file *dfile, struct drm_device *ddev,
>> + uint32_t handle)
>> +{
>> +return drm_gem_handle_delete(dfile, handle);
>> +}
> I wonder whether some dumb+gem helpers wouldn't be useful to roll out. At
> least drm_dumb_gem_destroy.c would be pretty simple.
There's already a drm_gem_dumb_destroy() in drm_gem.c
The drm_driver->gem_create_object callback makes it possible to do a
generic dumb create:
int drm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
struct drm_gem_object *obj;
int ret;
if (!dev->driver->gem_create_object)
return -EINVAL;
args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
args->size = args->pitch * args->height;
obj = dev->driver->gem_create_object(dev, args->size);
if (!obj)
return -ENOMEM;
ret = drm_gem_handle_create(file, obj, &args->handle);
drm_gem_object_unreference_unlocked(obj);
return ret;
}
EXPORT_SYMBOL(drm_gem_dumb_create);
struct drm_gem_object *sdrm_gem_create_object(struct drm_device *ddev,
size_t size)
{
struct sdrm_gem_object *sobj;
sobj = sdrm_gem_alloc_object(ddev, size);
if (!sobj)
return ERR_PTR(-ENOMEM);
return &sobj->base;
}
>> +
>> +int sdrm_dumb_map_offset(struct drm_file *dfile, struct drm_device *ddev,
>> + uint32_t handle, uint64_t *offset)
>> +{
>> +struct drm_gem_object *gobj;
>> +int r;
>> +
>> +mutex_lock(&ddev->struct_mutex);
> There's still some struct mutex here.
>
>> +
>> +gobj = drm_gem_object_lookup(dfile, handle);
>> +
[PATCH] drm: drop DRIVER_HAVE_IRQ flag for some drivers
On Fri, Aug 12, 2016 at 03:03:31PM +0100, Russell King - ARM Linux wrote: > On Fri, Aug 12, 2016 at 01:15:37PM +0800, Shawn Guo wrote: > > The drm driver feature flag DRIVER_HAVE_IRQ is used to indicates whether > > the driver has an IRQ handler managed by the DRM core. Some drivers, > > armada, etnaviv, kirin and sti, set this flag without .irq_handler setup > > in drm_driver. These drivers manage IRQ handler by themselves and the > > flag DRIVER_HAVE_IRQ makes no sense there. > > It's worth noting that DRIVER_HAVE_IRQ was required prior to: > > commit 4984979b9b9025a1cb9a9bea089d31a3e01ccff1 > Author: Daniel Vetter > Date: Wed Aug 28 15:02:37 2013 +0200 > > drm/irq: simplify irq checks in drm_wait_vblank > > to have working vblank. As this is no longer the case, this change > looks sane. Okay, I will improve the commit log and send v2 soon. > > > > > Drop the flag for these drivers to avoid confusion. > > > > Signed-off-by: Shawn Guo > > --- > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +-- > > For both of these, > > Acked-by: Russell King Thanks, Russell. Shawn
[PATCH] drm/rockchip: Delete unnecessary assignment for the field "owner"
From: Markus Elfring
Date: Tue, 16 Aug 2016 14:25:35 +0200
The field "owner" is set by the core.
Thus delete an unneeded initialisation.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 -
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 89aadbf..0e63ee2 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -445,7 +445,6 @@ static struct platform_driver rockchip_dp_driver = {
.remove = rockchip_dp_remove,
.driver = {
.name = "rockchip-dp",
- .owner = THIS_MODULE,
.pm = &rockchip_dp_pm_ops,
.of_match_table = of_match_ptr(rockchip_dp_dt_ids),
},
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 919992c..b7f59c4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -305,7 +305,6 @@ static struct platform_driver vop_platform_driver = {
.remove = vop_remove,
.driver = {
.name = "rockchip-vop",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(vop_driver_dt_match),
},
};
--
2.9.2
[PATCH] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
On Tue, Aug 16, 2016 at 2:35 PM, Lothar WaÃmann wrote: > On Tue, 16 Aug 2016 13:41:20 +0200 Lucas Stach wrote: >> Hi Lothar, >> >> Am Dienstag, den 16.08.2016, 13:12 +0200 schrieb Lothar WaÃmann: >> > Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in >> > the kerneldoc comments and add kerneldoc comments to the new function >> > drm_bus_flags_from_videomode(). >> > >> > Signed-off-by: Lothar WaÃmann >> > --- >> > drivers/gpu/drm/drm_modes.c | 10 ++ >> > 1 file changed, 10 insertions(+) >> > >> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> > index 1570487..e4c65bb 100644 >> > --- a/drivers/gpu/drm/drm_modes.c >> > +++ b/drivers/gpu/drm/drm_modes.c >> > @@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct >> > drm_display_mode *dmode, >> > } >> > EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode); >> > >> > +/** >> > + * drm_bus_flags_from_videomode - extract rmation about pixelclk and >> ^ missing letters here >> > OOOPS! Just found them under my keyboard. ;) > Should I resubmit or can whoever picks this up fix it when applying? Resubmit would be appreciated by me ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
Hi, On Tue, 16 Aug 2016 13:41:20 +0200 Lucas Stach wrote: > Hi Lothar, > > Am Dienstag, den 16.08.2016, 13:12 +0200 schrieb Lothar WaÃmann: > > Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in > > the kerneldoc comments and add kerneldoc comments to the new function > > drm_bus_flags_from_videomode(). > > > > Signed-off-by: Lothar WaÃmann > > --- > > drivers/gpu/drm/drm_modes.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > > index 1570487..e4c65bb 100644 > > --- a/drivers/gpu/drm/drm_modes.c > > +++ b/drivers/gpu/drm/drm_modes.c > > @@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct > > drm_display_mode *dmode, > > } > > EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode); > > > > +/** > > + * drm_bus_flags_from_videomode - extract rmation about pixelclk and > ^ missing letters here > OOOPS! Just found them under my keyboard. ;) Should I resubmit or can whoever picks this up fix it when applying? Lothar WaÃmann
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #27 from Kontantin Ivanov --- See my previous message for "4.4.0-34 DRI_PRIME=1 glxgears (stderr)" There is not any attachment for this. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #26 from Kontantin Ivanov --- When I start glxgears (on integrated Intel graphic card) the gears shown stdout is: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 305 frames in 5.0 seconds = 60.822 FPS 301 frames in 5.0 seconds = 60.030 FPS 301 frames in 5.0 seconds = 60.023 FPS stderr is: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 545 requests (545 known processed) with 0 events remaining. On the Radeon graphic card (DRI_PRIME=1) gears are not shown (black window). stdout is: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 17786 frames in 5.0 seconds = 3557.177 FPS stderr is: ... radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. radeon: The kernel rejected CS, see dmesg for more information. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 105710 requests (105710 known processed) with 0 events remaining. And `dmesg | tail` after `DRI_PRIME=1 glxgears` is [ 576.200519] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 577.216465] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 578.232004] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 578.251966] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, giving up!!! [ 578.252025] [drm:evergreen_startup.part.13 [radeon]] *ERROR* radeon: error initializing UVD (-1). [ 588.249875] radeon :01:00.0: ring 0 stalled for more than 1msec [ 588.249884] radeon :01:00.0: GPU lockup (current fence id 0x0005 last fence id 0x0006 on ring 0) [ 588.250001] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [ 588.250042] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 588.250064] [drm:radeon_resume_kms [radeon]] *ERROR* ib ring test failed (-35). I remember that with some kernel the Radeon card shows the gears normally. Tell me if I need to try all kernels one by one from current to latest. That's all Thank y'all for taking the time -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2] drm: drop DRIVER_HAVE_IRQ flag for some drivers
On Tue, Aug 16, 2016 at 03:06:08PM +0800, Shawn Guo wrote:
> Since commit 4984979b9b90 ("drm/irq: simplify irq checks in
> drm_wait_vblank"), the drm driver feature flag DRIVER_HAVE_IRQ is only
> required for drivers that have an IRQ handler managed by the DRM core.
> Some drivers, armada, etnaviv, kirin and sti, set this flag without
> .irq_handler setup in drm_driver. These drivers manage IRQ handler
> by themselves and the flag DRIVER_HAVE_IRQ makes no sense there.
>
> Drop the flag for these drivers to avoid confusion.
>
> Signed-off-by: Shawn Guo
> Cc: Vincent Abriou
> Cc: Xinliang Liu
> Acked-by: Russell King (for armada and
> etnaviv)
Applied to drm-misc, thanks.
-Daniel
> ---
> Changes for v2:
> - Improve commit log per Russell's suggestion
> - Add Russell's ACK tag
>
> drivers/gpu/drm/armada/armada_drv.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
> drivers/gpu/drm/sti/sti_drv.c | 2 +-
> 4 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index f5ebdd681445..1e0e68f608e4 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -211,7 +211,7 @@ static struct drm_driver armada_drm_driver = {
> .desc = "Armada SoC DRM",
> .date = "20120730",
> .driver_features= DRIVER_GEM | DRIVER_MODESET |
> - DRIVER_HAVE_IRQ | DRIVER_PRIME,
> + DRIVER_PRIME,
> .ioctls = armada_ioctls,
> .fops = &armada_drm_fops,
> };
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index ffd1b32caa8d..fd0ed61565f3 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -488,8 +488,7 @@ static const struct file_operations fops = {
> };
>
> static struct drm_driver etnaviv_drm_driver = {
> - .driver_features= DRIVER_HAVE_IRQ |
> - DRIVER_GEM |
> + .driver_features= DRIVER_GEM |
> DRIVER_PRIME |
> DRIVER_RENDER,
> .open = etnaviv_open,
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 1edd9bc80294..1fc2f502d20d 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -169,7 +169,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file
> *file,
>
> static struct drm_driver kirin_drm_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> - DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
> + DRIVER_ATOMIC,
> .fops = &kirin_drm_fops,
>
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 96bd3d08b2d4..f8311b2bc84e 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -282,7 +282,7 @@ static const struct file_operations sti_driver_fops = {
> };
>
> static struct drm_driver sti_driver = {
> - .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
> + .driver_features = DRIVER_MODESET |
> DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[FIXUP] drm: remove `const` attribute to hint at caller that they now own the memory
On Tue, Aug 16, 2016 at 02:04:21PM +0300, Jani Nikula wrote:
>
> Reviewed-by: Jani Nikula
Applied to drm-misc, thanks.
-Daniel
>
>
> On Mon, 15 Aug 2016, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> > drivers/gpu/drm/drm_atomic.c| 2 +-
> > drivers/gpu/drm/drm_crtc.c | 8
> > drivers/gpu/drm/drm_fourcc.c| 4 ++--
> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
> > drivers/gpu/drm/i915/intel_display.c| 4 ++--
> > drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++--
> > include/drm/drm_fourcc.h| 2 +-
> > 12 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index 0bf8959..741da36 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > @@ -2071,7 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> > *crtc,
> > u32 tmp, viewport_w, viewport_h;
> > int r;
> > bool bypass_lut = false;
> > - const char *format_name;
> > + char *format_name;
> >
> > /* no fb bound */
> > if (!atomic && !crtc->primary->fb) {
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > index 1558a97..2282eb6 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > @@ -2046,7 +2046,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc
> > *crtc,
> > u32 tmp, viewport_w, viewport_h;
> > int r;
> > bool bypass_lut = false;
> > - const char *format_name;
> > + char *format_name;
> >
> > /* no fb bound */
> > if (!atomic && !crtc->primary->fb) {
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > index 71a0375..8b7ad34 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > @@ -1952,7 +1952,7 @@ static int dce_v8_0_crtc_do_set_base(struct drm_crtc
> > *crtc,
> > u32 viewport_w, viewport_h;
> > int r;
> > bool bypass_lut = false;
> > - const char *format_name;
> > + char *format_name;
> >
> > /* no fb bound */
> > if (!atomic && !crtc->primary->fb) {
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 087391f..5cb2e22 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -837,7 +837,7 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > /* Check whether this plane supports the fb pixel format. */
> > ret = drm_plane_check_pixel_format(plane, state->fb->pixel_format);
> > if (ret) {
> > - const char *format_name =
> > drm_get_format_name(state->fb->pixel_format);
> > + char *format_name =
> > drm_get_format_name(state->fb->pixel_format);
> > DRM_DEBUG_ATOMIC("Invalid pixel format %s\n", format_name);
> > kfree(format_name);
> > return ret;
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 7da5d33..30ab28b 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2592,7 +2592,7 @@ static int __setplane_internal(struct drm_plane
> > *plane,
> > /* Check whether this plane supports the fb pixel format. */
> > ret = drm_plane_check_pixel_format(plane, fb->pixel_format);
> > if (ret) {
> > - const char *format_name = drm_get_format_name(fb->pixel_format);
> > + char *format_name = drm_get_format_name(fb->pixel_format);
> > DRM_DEBUG_KMS("Invalid pixel format %s\n", format_name);
> > kfree(format_name);
> > goto out;
> > @@ -2903,7 +2903,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void
> > *data,
> > ret = drm_plane_check_pixel_format(crtc->primary,
> >fb->pixel_format);
> > if (ret) {
> > - const char *format_name =
> > drm_get_format_name(fb->pixel_format);
> > + char *format_name =
> > drm_get_format_name(fb->pixel_format);
> > DRM_DEBUG_KMS("Invalid pixel format %s\n",
> > format_name);
> > kfree(format_name);
> > goto out;
> > @@ -3281,7 +3281,7 @@ int drm_mode_addfb(struct drm_device *dev,
> > static int format_check(const struct drm_mode_fb_cmd2 *r)
> > {
> > uint32_t format = r->pixel_format & ~DRM_FORMAT_B
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #25 from Kontantin Ivanov --- Created attachment 229111 --> https://bugzilla.kernel.org/attachment.cgi?id=229111&action=edit 4.4.0-34 DRI_PRIME=1 glxinfo (descret Radeon graphic card) stderr is empty -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #24 from Kontantin Ivanov --- Created attachment 229101 --> https://bugzilla.kernel.org/attachment.cgi?id=229101&action=edit 4.4.0-34 glxinfo (integraded Intel graphic card) -- You are receiving this mail because: You are watching the assignee of the bug.
[FIXUP] drm: remove `const` attribute to hint at caller that they now own the memory
Reviewed-by: Jani Nikula
On Mon, 15 Aug 2016, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/drm_atomic.c| 2 +-
> drivers/gpu/drm/drm_crtc.c | 8
> drivers/gpu/drm/drm_fourcc.c| 4 ++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c| 4 ++--
> drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++--
> include/drm/drm_fourcc.h| 2 +-
> 12 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 0bf8959..741da36 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2071,7 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - const char *format_name;
> + char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 1558a97..2282eb6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -2046,7 +2046,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - const char *format_name;
> + char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 71a0375..8b7ad34 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1952,7 +1952,7 @@ static int dce_v8_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - const char *format_name;
> + char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 087391f..5cb2e22 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -837,7 +837,7 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
> /* Check whether this plane supports the fb pixel format. */
> ret = drm_plane_check_pixel_format(plane, state->fb->pixel_format);
> if (ret) {
> - const char *format_name =
> drm_get_format_name(state->fb->pixel_format);
> + char *format_name =
> drm_get_format_name(state->fb->pixel_format);
> DRM_DEBUG_ATOMIC("Invalid pixel format %s\n", format_name);
> kfree(format_name);
> return ret;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7da5d33..30ab28b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2592,7 +2592,7 @@ static int __setplane_internal(struct drm_plane *plane,
> /* Check whether this plane supports the fb pixel format. */
> ret = drm_plane_check_pixel_format(plane, fb->pixel_format);
> if (ret) {
> - const char *format_name = drm_get_format_name(fb->pixel_format);
> + char *format_name = drm_get_format_name(fb->pixel_format);
> DRM_DEBUG_KMS("Invalid pixel format %s\n", format_name);
> kfree(format_name);
> goto out;
> @@ -2903,7 +2903,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> ret = drm_plane_check_pixel_format(crtc->primary,
> fb->pixel_format);
> if (ret) {
> - const char *format_name =
> drm_get_format_name(fb->pixel_format);
> + char *format_name =
> drm_get_format_name(fb->pixel_format);
> DRM_DEBUG_KMS("Invalid pixel format %s\n",
> format_name);
> kfree(format_name);
> goto out;
> @@ -3281,7 +3281,7 @@ int drm_mode_addfb(struct drm_device *dev,
> static int format_check(const struct drm_mode_fb_cmd2 *r)
> {
> uint32_t format = r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN;
> - const char *format_name;
> + char *format_name;
>
> switch (format) {
> case DRM_FORMAT_C8:
> @@ -3359,7 +3359,7 @@ static int framebuffer_check(const struct
> drm_mode_fb_cmd2 *r)
>
> ret = format
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #23 from Kontantin Ivanov --- Created attachment 229091 --> https://bugzilla.kernel.org/attachment.cgi?id=229091&action=edit 4.4.0-34 Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #22 from Kontantin Ivanov --- Created attachment 229081 --> https://bugzilla.kernel.org/attachment.cgi?id=229081&action=edit 4.4.0-34 dmesg 4.4.0-34 dmesg after system start & login -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #21 from Kontantin Ivanov --- Sorry for late reply. So. I reinstall my Kubuntu completely to be sure that some install/purge ppa/firmware/etc doesn't affect the system. Now `uname -a` is: Linux hpg6 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux My Radeon card doesn't render anything (black window) but looks like it works. When I start glxgears it shows FPS but window is black and stderr is full of (see "4.4.0-34 DRI_PRIME=1 glxgears (stderr)" attachment). The "UDV not responding..." error is also present (as usual). [ 576.200519] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 577.216465] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 578.232004] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 578.251966] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, giving up!!! [ 578.252025] [drm:evergreen_startup.part.13 [radeon]] *ERROR* radeon: error initializing UVD (-1). [ 588.249875] radeon :01:00.0: ring 0 stalled for more than 1msec [ 588.249884] radeon :01:00.0: GPU lockup (current fence id 0x0005 last fence id 0x0006 on ring 0) [ 588.250001] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [ 588.250042] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35). [ 588.250064] [drm:radeon_resume_kms [radeon]] *ERROR* ib ring test failed (-35). I'm going to attach 4.4.0-34 files: dmesg, Xorg.0.log etc now Tell me if I need to update my kernel to rc or another release. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/bridge: dw-hdmi: Delete unnecessary assignment for the field "owner"
From: Markus Elfring
Date: Tue, 16 Aug 2016 13:52:19 +0200
The field "owner" is set by the core.
Thus delete an unneeded initialisation.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
index 122bb01..8f2d137 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
@@ -640,7 +640,6 @@ static struct platform_driver snd_dw_hdmi_driver = {
.remove = snd_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
- .owner = THIS_MODULE,
.pm = PM_OPS,
},
};
--
2.9.2
[PATCH] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
Hi Lothar,
Am Dienstag, den 16.08.2016, 13:12 +0200 schrieb Lothar WaÃmann:
> Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in
> the kerneldoc comments and add kerneldoc comments to the new function
> drm_bus_flags_from_videomode().
>
> Signed-off-by: Lothar WaÃmann
> ---
> drivers/gpu/drm/drm_modes.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 1570487..e4c65bb 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct
> drm_display_mode *dmode,
> }
> EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
>
> +/**
> + * drm_bus_flags_from_videomode - extract rmation about pixelclk and
^ missing letters here
> + * DE polarity from videomode and store it in a separate variable
> + * @vm: videomode structure to use
> + * @bus_flags: information about pixelclk and DE polarity will be stored here
> + *
> + * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
> + * in @bus_flags according to DISPLAY_FLAGS found in @vm
> + */
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
> {
> *bus_flags = 0;
> @@ -677,6 +686,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
> * of_get_drm_display_mode - get a drm_display_mode from devicetree
> * @np: device_node with the timing specification
> * @dmode: will be set to the return value
> + * @bus_flags: information about pixelclk and DE polarity
> * @index: index into the list of display timings in devicetree
> *
> * This function is expensive and should only be used, if only one mode is
> to be
[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem
Hi Shuah, 2016ë 08ì 13ì¼ 02:52ì Shuah Khan ì´(ê°) ì´ ê¸: > On 08/12/2016 11:28 AM, Shuah Khan wrote: >> On 08/10/2016 05:05 PM, Shuah Khan wrote: >>> On 08/10/2016 04:59 PM, Inki Dae wrote: Hi Shuah, 2016ë 08ì 11ì¼ 02:30ì Shuah Khan ì´(ê°) ì´ ê¸: > Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM > memory without IOMMU. In this case, there is no point in attempting to DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia device and other DMA devices. Even though IOMMU support is disabled, other framework based DMA drivers can use IOMMU - i.e., GPU driver - and they can use non-contiguous GEM buffer through UMM. (DMABUF) So GEM allocation type is not dependent on IOMMU. >>> >>> Hi Inki, >>> >>> I am seeing the following failure without IOMMU and light dm fails >>> to start: >>> >>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not >>> supported. >>> >>> The change I made fixed that problem and light dm starts without IOMMU. >>> Is there a better way to fix this problem? Currently without IOMMU, >>> light dm doesn't start. >>> >>> This is on linux_next >> >> Hi Inki, >> >> I am looking into this further and I am finding inconsistent >> commits with regards to GEM contiguous and non-contiguous >> buffers. >> >> Okay what you said is that: >> >> exymod-drm should support non-continguous and contiguous GEM memory >> type with or without IOMMU Right. >> >> However, the code currently isn't doing that. The following >> commit allocates non-contiguous buffers when IOMMU is enabled >> to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> IOMMU is disabled: >> >> exynos_drm_gem_create_ioctl() gets called with NONCONTIG >> - driver should try to allocate non-contig >> - if it can't allocate non-contig, allocate contig >> ( this will allow avoid failure like the one I am seeing) >> >> exynos_drm_gem_create_ioctl() gets called with CONTIG >> - driver should try to allocate contig >> - if it can't allocate contig, allocate non-contig >> >> What is confusing is there are several code paths in the >> GEN allocation and checking memory types are enforcing >> non-contig with IOMMU. Check this routine: >> >> exynos_drm_framebuffer_init() will reject non-contig >> memory type when check_fb_gem_memory_type() rejects >> non-contig GEM memory type without IOMMU. Only in case that the gem buffer is used for framebuffer, gem memory type should be checked because this means the DMA of Display controller accesses the gem buffer so without IOMMU the DMA device cannot access non-contiguous memory region. That is why exynos_drm_framebuffer_init checks gem memory type for fb not when gem is created. > > > okay the very first commit that added IOMMU support > introduced the code that rejects non-contig gem memory > type without IOMMU. > > commit 0519f9a12d0113caab78980c48a7902d2bd40c2c > Author: Inki Dae > Date: Sat Oct 20 07:53:42 2012 -0700 > > drm/exynos: add iommu support for exynos drm framework > > Anyway, if it is th right change to fix check_fb_gem_memory_type() > to not reject NONCONTIG_BUFFER, then I can make that change No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer. You would need to understand that gem buffer can be used for other purposes - 2D/3D or post process devices which don't use framebuffer - not display controller which uses framebuffer to scanout Thanks, Inki Dae > instead of this patch I sent. > >> >> So there is inconsistency in the non-contig vs. contig >> GEM support in exynos-drm. I think this needs to be cleaned >> up to get the desired behavior. >> >> The following commit allocates non-contiguous buffers when IOMMU is >> enabled to handle contiguous allocation failures. >> >> There are other commits that removed checks for non-contig type. >> Let's look at the following cases to see what should be the driver >> behavior in these cases: >> >> commit 122beea84bb90236b1ae545f08267af58591c21b >> Author: Rahul Sharma >> Date: Wed May 7 17:21:29 2014 +0530 >> >> drm/exynos: allocate non-contigous buffers when iommu is enabled >> >> Allow to allocate non-contigous buffers when iommu is enabled. >> Currently, it tries to allocates contigous buffer which consistently >> fail for large buffers and then fall back to non contigous. Apart >> from being slow, this implementation is also very noisy and fills >> the screen with alloc fail logs. >> >> Signed-off-by: Rahul Sharma >> Reviewed-by: Sachin Kamat >> Signed-off-by: Inki Dae >> >> >> commit ea6d66c3a797376d21b23dc8261733ce35970014 >> Author: Inki Dae >> Date: Fri Nov 2
[PATCH v4] drm: Introduce DRM_DEV_* log messages
On Mon, Aug 15, 2016 at 04:18:04PM -0700, Sean Paul wrote:
> This patch consolidates all the various log functions/macros into
> one uber function, drm_log. It also introduces some new DRM_DEV_*
> variants that print the device name to delineate multiple devices
> of the same type.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
> Changes in v3:
> - Rename drm_log to drm_dev_printk (Chris Wilson)
> - Break out drm_printk from drm_dev_printk to reduce
> image growth due to passing NULL around (Chris Wilson)
>
> Changes in v4:
> - Pull format string out into #define (Eric Engestrom)
>
>
> drivers/gpu/drm/drm_drv.c | 27 ++---
> include/drm/drmP.h| 140
> +++---
> 2 files changed, 103 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 57ce973..a7f6282 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -63,37 +63,48 @@ static struct idr drm_minors_idr;
>
> static struct dentry *drm_debugfs_root;
>
> -void drm_err(const char *format, ...)
> +#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> +
> +void drm_dev_printk(const struct device *dev, const char *level,
> + unsigned int category, const char *function_name,
> + const char *prefix, const char *format, ...)
> {
> struct va_format vaf;
> va_list args;
>
> - va_start(args, format);
> + if (category != DRM_UT_NONE && !(drm_debug & category))
> + return;
>
> + va_start(args, format);
> vaf.fmt = format;
> vaf.va = &args;
>
> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> -__builtin_return_address(0), &vaf);
> + dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
> +&vaf);
>
> va_end(args);
> }
> -EXPORT_SYMBOL(drm_err);
> +EXPORT_SYMBOL(drm_dev_printk);
>
> -void drm_ut_debug_printk(const char *function_name, const char *format, ...)
> +void drm_printk(const char *level, unsigned int category,
> + const char *function_name, const char *prefix,
> + const char *format, ...)
> {
> struct va_format vaf;
> va_list args;
>
> + if (category != DRM_UT_NONE && !(drm_debug & category))
> + return;
> +
> va_start(args, format);
> vaf.fmt = format;
> vaf.va = &args;
>
> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
> + printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
>
> va_end(args);
> }
> -EXPORT_SYMBOL(drm_ut_debug_printk);
> +EXPORT_SYMBOL(drm_printk);
>
> /*
> * DRM Minors
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index f8e87fd..94eb138 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -127,6 +127,7 @@ struct dma_buf_attachment;
> * run-time by echoing the debug value in its sysfs node:
> * # echo 0xf > /sys/module/drm/parameters/debug
> */
> +#define DRM_UT_NONE 0x00
> #define DRM_UT_CORE 0x01
> #define DRM_UT_DRIVER0x02
> #define DRM_UT_KMS 0x04
> @@ -134,11 +135,15 @@ struct dma_buf_attachment;
> #define DRM_UT_ATOMIC0x10
> #define DRM_UT_VBL 0x20
>
> -extern __printf(2, 3)
> -void drm_ut_debug_printk(const char *function_name,
> - const char *format, ...);
> -extern __printf(1, 2)
> -void drm_err(const char *format, ...);
> +extern __printf(6, 7)
> +void drm_dev_printk(const struct device *dev, const char *level,
> + unsigned int category, const char *function_name,
> + const char *prefix, const char *format, ...);
> +
> +extern __printf(5, 6)
> +void drm_printk(const char *level, unsigned int category,
> + const char *function_name, const char *prefix,
> + const char *format, ...);
>
> /***/
> /** \name DRM template customization defaults */
> @@ -169,8 +174,12 @@ void drm_err(const char *format, ...);
> * \param fmt printf() like format string.
> * \param arg arguments
> */
> -#define DRM_ERROR(fmt, ...) \
> - drm_err(fmt, ##__VA_ARGS__)
> +#define DRM_DEV_ERROR(dev, fmt, ...) \
> + drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
> +fmt, ##__VA_ARGS__)
> +#define DRM_ERROR(fmt, ...) \
> + drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
> +##__VA_ARGS__)
>
> /**
> * Rate limited error output. Like DRM_ERROR() but won't flood the log.
> @@ -178,21 +187,33 @@ void drm_err(const char *format, ...);
> * \param fmt printf() like format string.
> * \param arg arguments
> */
> -#de
[Bug 119831] "nomodeset" required to boot - MSI laptop G72 6QE, nouveau graphics
https://bugzilla.kernel.org/show_bug.cgi?id=119831 --- Comment #14 from Pierre Moreau --- Eh sorry, completely forgot that you answered. So, you usually have a Xorg.0.log and a Xorg.0.log.old, with the former one being the log for the current session, and the latter one, of the previous session. If you use systemd, you can get the previous kernel log using `journalctl -b -1`. By the way, you should remove the xf86-video-nouveau driver as it does not support your chipset. X will, and already does, fallback to the modesetting driver. It might be related to https://bugs.freedesktop.org/show_bug.cgi?id=94725. Could you try if that patch https://bugs.freedesktop.org/attachment.cgi?id=122653 helps? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: update kerneldoc for changes introduced by commits "16fadc2568e9" and "9671e228fb78"
Describe the new parameter 'bus_flags' to of_get_drm_display_mode() in
the kerneldoc comments and add kerneldoc comments to the new function
drm_bus_flags_from_videomode().
Signed-off-by: Lothar WaÃmann
---
drivers/gpu/drm/drm_modes.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1570487..e4c65bb 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -657,6 +657,15 @@ void drm_display_mode_to_videomode(const struct
drm_display_mode *dmode,
}
EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
+/**
+ * drm_bus_flags_from_videomode - extract rmation about pixelclk and
+ * DE polarity from videomode and store it in a separate variable
+ * @vm: videomode structure to use
+ * @bus_flags: information about pixelclk and DE polarity will be stored here
+ *
+ * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
+ * in @bus_flags according to DISPLAY_FLAGS found in @vm
+ */
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags)
{
*bus_flags = 0;
@@ -677,6 +686,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
* of_get_drm_display_mode - get a drm_display_mode from devicetree
* @np: device_node with the timing specification
* @dmode: will be set to the return value
+ * @bus_flags: information about pixelclk and DE polarity
* @index: index into the list of display timings in devicetree
*
* This function is expensive and should only be used, if only one mode is to
be
--
2.1.4
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On 16/08/16 12:49 PM, Deng, Emily wrote: > Hi Michel, Thanks, I still couldn't see the issue that use a variable > to calculate the vblank count when vsync timer interrupt occurs. I > just think it only emulates the hardware behavior. And the code > change will only in virtual display files which won't touch drm > layer. I incline to not modify the code in drm layer or amdgpu other > codes, because it may lead to other issues . I see it basically the other way around: We are currently pretending to the DRM core code that we have a reliable hardware vblank counter and timing even in the virtual DCE case, when we really don't. We should stop pretending and instead communicate the lack of these hardware facilities in the virtual DCE case as intended, otherwise we'll probably run into issues sooner or later. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 4/4] ARM: dts: am335x-boneblack: Convert BGR from LCDC to RGB in tda19988
Convert BGR from LCDC to RGB in tda19988 with video-ports property.
The red and blue components are reversed between 24 and 16 bit modes
on color output of am335x LCDC. On BBB the 16 bit video output is by
default RGB and 24 is BGR. This patch reverts that using tda19988 so
we have a 24 bit RGB mode and 16 BGR mode.
The commit also adds blue-and-red-wiring = "crossed" -property to LCDC
node. This change is functionally redundant as "crossed" is the
default mode if the property does not exist, but it makes the reason
for tda19988 video-port property mode explicit.
If you want to get 16 RGB mode (and 24 BGR mode), set tda19988
video-ports -property to 0x230145 and tilcdc blue-and-red-wiring
-property to "straight".
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 528559b..a745962 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -90,6 +90,14 @@
&lcdc {
status = "okay";
+
+ /* If you want to get 16 RGB and 24 BGR mode instead of
+* current 24 bit RGB and 16 BGR modes, set this property to
+* "straight" and the tda19988 video-ports -property bellow
+* to 0x230145 (or remove the property).
+*/
+ blue-and-red-wiring = "crossed";
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <&hdmi_0>;
@@ -106,6 +114,9 @@
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
+ video-ports = <0x234501>;
+
#sound-dai-cells = <0>;
audio-ports = < TDA998x_I2S 0x03>;
--
1.9.1
[PATCH 3/4] drm/tilcdc: Choose console BPP that supports RGB
Choose console BPP that supports RGB and remove the old fbdev bpp
selection code. LCDC on AM335x has red and blue wires switched between
24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16
bit format is wired for BGR. drm_fbdev_cma_init() does not currently
like anything else but RGB formats, so we must choose such bytes per
pixel value that supports RGB.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 -
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 -
drivers/gpu/drm/tilcdc/tilcdc_external.c | 7 +++
drivers/gpu/drm/tilcdc/tilcdc_external.h | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_panel.c| 2 --
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 2 --
6 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 7f9c19d..bb7af14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -256,7 +256,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
- struct tilcdc_module *mod;
struct resource *res;
u32 bpp = 0;
int ret;
@@ -352,14 +351,17 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
DBG("Revision 1 LCDC supports only RGB565 format");
priv->pixelformats = tilcdc_rev1_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+ bpp = 16;
} else if (tilcdc_of_blue_and_red_crossed(node)) {
DBG("Configured for crossed blue and red wires");
priv->pixelformats = tilcdc_crossed_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_crossed_formats);
+ bpp = 32; /* Choose bpp with RGB support for fbdef */
} else {
DBG("Configured for straight blue and red wires");
priv->pixelformats = tilcdc_straight_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_straight_formats);
+ bpp = 16; /* Choose bpp with RGB support for fbdef */
}
ret = modeset_init(dev);
@@ -375,7 +377,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
if (ret < 0)
goto fail_mode_config_cleanup;
- ret = tilcdc_add_external_encoders(dev, &bpp);
+ ret = tilcdc_add_external_encoders(dev);
if (ret < 0)
goto fail_component_cleanup;
}
@@ -398,13 +400,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
goto fail_vblank_cleanup;
}
- list_for_each_entry(mod, &module_list, list) {
- DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
- bpp = mod->preferred_bpp;
- if (bpp > 0)
- break;
- }
-
drm_mode_config_reset(dev);
priv->fbdev = drm_fbdev_cma_init(dev, bpp,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0e19c14..a6e5e6d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
- unsigned int preferred_bpp;
};
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 849b23e..68e8950 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -52,7 +52,7 @@ static int tilcdc_external_mode_valid(struct drm_connector
*connector,
return MODE_OK;
}
-static int tilcdc_add_external_encoder(struct drm_device *dev, int *bpp,
+static int tilcdc_add_external_encoder(struct drm_device *dev,
struct drm_connector *connector)
{
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -64,7 +64,6 @@ static int tilcdc_add_external_encoder(struct drm_device
*dev, int *bpp,
/* Only tda998x is supported at the moment. */
tilcdc_crtc_set_simulate_vesa_sync(priv->crtc, true);
tilcdc_crtc_set_panel_info(priv->crtc, &panel_info_tda998x);
- *bpp = panel_info_tda998x.bpp;
connector_funcs = devm_kzalloc(dev->dev, sizeof(*connector_funcs),
GFP_KERNEL);
@@ -94,7 +93,7 @@ static int tilcdc_add_external_encoder(struct drm_device
*dev, int *bpp,
return 0;
}
-int tilcdc_add_external_encoders(struct drm_device *dev, int *bpp)
+int tilcdc_add_external_encoders(struct drm_device *dev)
{
struct tilcdc_drm_private *priv = dev->dev_private;
[PATCH 2/4] drm/tilcdc: Add blue-and-red-wiring -device tree property
Add "blue-and-red-wiring"-device tree property and update devicetree
binding document. The red and blue components are reversed between 24
and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the
red and blue wires has to be crossed and this in turn causes 16 colors
output to be in BGR format. With straight wiring the 16 color is RGB
and 24 bit is BGR. The new property describes whether the red and blue
wires are crossed or not. The am335x-evm has the wires going to LCD
crossed and that is chosen to be the default mode if
"blue-and-red-wiring"-property is not found.
For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/display/tilcdc/tilcdc.txt | 12 ++
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 44 ++
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 4 ++
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 9 ++---
4 files changed, 63 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 6efa4c5..992803b 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -17,6 +17,8 @@ Optional properties:
the lcd controller.
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+ - blue-and-red-wiring: Either "crossed" or "straight", if not present
+ crossed wiring is assumed for dtb backward compatibility. [1]
Optional nodes:
@@ -28,6 +30,14 @@ Optional nodes:
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
tfp410 DVI encoder or lcd panel to lcdc
+[1] There is an errata about AM335x color wiring. For 16-bit color mode
+the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]),
+but for 24 bit color modes the wiring of blue and red components is
+crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
+for Blue[3-7]. For more details see section 3.1.1 in AM335x
+Silicon Errata:
+
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
+
Example:
fb: fb at 4830e000 {
@@ -37,6 +47,8 @@ Example:
interrupts = <36>;
ti,hwmods = "lcdc";
+ blue-and-red-wiring = "crossed";
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <&hdmi_0>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index e45c268..7f9c19d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -33,6 +33,16 @@
static LIST_HEAD(module_list);
+static const u32 tilcdc_rev1_formats[] = { DRM_FORMAT_RGB565 };
+
+static const u32 tilcdc_straight_formats[] = { DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_XBGR };
+
+static const u32 tilcdc_crossed_formats[] = { DRM_FORMAT_BGR565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_XRGB };
+
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
{
@@ -221,6 +231,26 @@ static int tilcdc_unload(struct drm_device *dev)
return 0;
}
+static bool tilcdc_of_blue_and_red_crossed(struct device_node *node)
+{
+ const char *str;
+ int ret;
+
+ ret = of_property_read_string(node, "blue-and-red-wiring", &str);
+
+ /* If no property is present, assume that wires are crossed */
+ if (ret != 0)
+ return true;
+
+ DBG("blue-and-red-wiring = \"%s\"", str);
+
+ /* Unless property is "crossed", assume the wires are straight */
+ if (0 == strcmp(str, "crossed"))
+ return true;
+
+ return false;
+}
+
static int tilcdc_load(struct drm_device *dev, unsigned long flags)
{
struct platform_device *pdev = dev->platformdev;
@@ -318,6 +348,20 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
pm_runtime_put_sync(dev->dev);
+ if (priv->rev == 1) {
+ DBG("Revision 1 LCDC supports only RGB565 format");
+ priv->pixelformats = tilcdc_rev1_formats;
+ priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+ } else if (tilcdc_of_blue_and_red_crossed(node)) {
+ DBG("Configured for crossed blue and red wires");
+ priv->pixelformats = tilcdc_crossed_formats;
+ priv->num_pixelformats = ARRAY_SIZE(tilcdc_crossed_formats);
+ } else {
+ DBG("Configured for straight blue and red wires");
+ priv->pixelfor
[PATCH 1/4] drm/tilcdc: Remove drm_helper_disable_unused_functions() call
drm_helper_disable_unused_functions() should not be called by atomic drivers. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 3404d24..e45c268 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -361,8 +361,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned long flags) break; } - drm_helper_disable_unused_functions(dev); - drm_mode_config_reset(dev); priv->fbdev = drm_fbdev_cma_init(dev, bpp, -- 1.9.1
[PATCH 0/4] drm/tilcdc: Address LCDC rev 2 color errata
The first patch ("drm/tilcdc: Remove drm_helper_disable_unused_functions()
call") is completely independent fix.
The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the wires red and
blue wires has to be crossed and this in turn causes 16 colors output
to be in BGR format. With straight wiring the 16 color is RGB and 24
bit is BGR. These patches try to deal with the issue in reasonable
manner.
For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
Jyri Sarha (4):
drm/tilcdc: Remove drm_helper_disable_unused_functions() call
drm/tilcdc: Add blue-and-red-wiring -device tree property
drm/tilcdc: Choose console BPP that supports RGB
ARM: dts: am335x-boneblack: Convert BGR from LCDC to RGB in tda19988
.../devicetree/bindings/display/tilcdc/tilcdc.txt | 12 +
arch/arm/boot/dts/am335x-boneblack.dts | 11
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 59 ++
drivers/gpu/drm/tilcdc/tilcdc_drv.h| 5 +-
drivers/gpu/drm/tilcdc/tilcdc_external.c | 7 ++-
drivers/gpu/drm/tilcdc/tilcdc_external.h | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 -
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 9 ++--
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 2 -
9 files changed, 82 insertions(+), 27 deletions(-)
--
1.9.1
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On 15/08/16 03:45 PM, Deng, Emily wrote: >> From: Michel Dänzer [mailto:michel at daenzer.net] >> Sent: Monday, August 15, 2016 9:46 AM >> On 11/08/16 12:46 PM, Emily Deng wrote: >>> The adev->ddev->vblank[crtc].count couldn't be used here, so define >>> another variable to compute the vblank count. >>> >>> Signed-off-by: Emily Deng >> >> [...] >> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c >>> b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c >>> index 2ce5f90..d616ab9 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c >>> @@ -58,7 +58,7 @@ static u32 dce_virtual_vblank_get_counter(struct >> amdgpu_device *adev, int crtc) >>> if (crtc >= adev->mode_info.num_crtc) >>> return 0; >>> else >>> - return adev->ddev->vblank[crtc].count; >>> + return adev->mode_info.timer_vblank_count; >>> } >> >> AFAIK the vblank_get_counter hook is supposed to always return 0 when >> there's no hardware frame counter which can be used. That's what >> drm_vblank_no_hw_counter was created for. >> > [[EmilyD]] Sorry, I don't know much about drm_vblank_no_hw_counter, can it > support vsync when > return to 0? That's its purpose. BTW, I realized in the meantime that we can't use drm_vblank_no_hw_counter directly, because there's a single struct drm_driver used by all amdgpu driver instances. >> You mentioned internally that you ran into trouble when trying this though. >> Please provide more information about that, e.g.: Which base kernel version >> did >> you test it with? What values did the DRM_IOCTL_WAIT_VBLANK ioctl return to >> userspace? ... >> > [[EmilyD]] I run the driver on kernel version 4.6, and run glxgears with > vsync enabled. It is hard to detail the issue, I will try my best to > description > the issue I found. > After I double checked, it is not segment fault in libGL.so when run > glxgears with vsync, but the glxgears will be stucked in waiting for the > before > swap buffers to complete. This is because when enable vsync, every time swap > buffers, the DDX driver will call DRM_IOCTL_WAIT_VBLANK to > queue the vblank event, and the vbl.request.sequence will be set to > current_vblank_count + swap_interval. Then in kernel driver, when timer > interrupt occurs, it will call drm_handle_vblank_events, it will call > drm_vblank_count_and_time to get current seq, and only seq >= > vbl.request.sequence, > then will call send_vblank_event. So it will never call send_vblank_event. > For example, the DDX driver call DRM_IOCTL_WAIT_VBLANK , then kernel driver > will call drm_queue_vblank_event, and current vblank_count is 1 > (As we only return 0 in vblank_get_counter, so the vblank_count will never > change except calling drm_reset_vblank_timestamp which will make > adev->ddev->vblank[crtc].count++), and swap_interval is 1, then > vbl.request.sequence will be 2, but the drm_vblank_count_and_time will always > return 1 except calling drm_reset_vblank_timestamp(The function > drm_reset_vblank_timestamp will only be called in drm_vblank_post_modeset > and drm_vblank_on ), so the send_vblank_event will never be called, and swap > buffers won't complete, so the glxgears will be stucked. Looking at the drm_update_vblank_count() code, you also need to do the following in the virtual DCE case: * Set dev->max_vblank_count = 0 * Make amdgpu_get_vblank_timestamp_kms either return values based on when the virtual vblank interrupt timer last fired, or just return a negative error code immediately, instead of calling drm_calc_vbltimestamp_from_scanoutpos * Make amdgpu_get_vblank_counter_kms take the else path (or just return 0 immediately), not run any of the scanout position related code -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 4/6] drm/radeon: Provide page_flip_target hook
On 16/08/16 09:35 AM, Mario Kleiner wrote: > Hi Michel, > > sorry for the super-late reply, i was just catching up with all the > mails and discussions, starting in June, leading to this patch set. > > Looks all pretty good. > > I'll look at this radeon patch and 2/6 for amdgpu later this week when i > have a fresh brain and enough "obsessive compulsive time", to make sure > all the magic wrt. "virtually extended vblank" and the fudging logic is > fine. Excellent! > I'll then also run it through my timing tests. I assume the > ati/amdgpu-ddx patches and libdrm patches in your freedesktop home are > all i need for testing? Yes, although it would also be nice to test with unmodified userspace and make sure there are no regressions with that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2
On 16/08/16 10:32 AM, Mario Kleiner wrote:
> Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland.
>
> Wrt. having a new pageflip parameter struct, i wonder if it wouldn't
> make sense to then already prepare some space in it for specifying an
> absolute target time, e.g., in u64 microseconds? Or make this part of
> the atomic pageflip framework?
I feel like this is too much hassle for the DRM_IOCTL_MODE_PAGE_FLIP
ioctl, probably makes sense to only deal with this in the atomic API.
> In Wayland we now have the presentation_feedback extension (maybe it got
> a new name?), which is great to get feedback when and how presentation
> was completed, essentially the equivalent of X11's GLX_INTEL_swap_events
> + some useful extra info / the feedback half of OML_sync_control.
>
> That was supposed to be complemented by a presentation_queue extension
> which would provide the other half of OML_sync_control, the part where
> an app can tell the compositor when and how to present surface updates.
> I remember that a year ago inclusion of that extension was blocked on
> some other more urgent important blocker bugs? Did this make progress?
> For timing sensitive applications such an extension is even more
> important in a wayland world than under X11. On X11 most desktops allow
> unredirecting fullscreen windows, so an app can drive the flip timing
> rather direct. At least on Weston as i remember it from my last tests a
> year ago, that wasn't possible, and an app that doesn't want to present
> at each video refresh, but at specific target times had to guess what
> the specific compositors scheduling strategy might be and then "play
> games" wrt. to timing surface commit's to trick the compositor into sort
> of doing the right thing - very fragile.
>
> Anyway, the idea of presentation_queue was to specify the requested time
> of presentation as actual time, not as a target vblank count. This
> because applications that care about precise presentation timing, like
> my kind of neuroscience/medical visual stimulation software, or also
> video players, or e.g., at least the VDPAU video presentation api
> "think" in absolute time, not in refresh cycles. Also a target vblank
> count for presentation is less meaningful than a target time for things
> like variable framerate displays/adaptive sync, or displays which don't
> have a classic refresh cycle at all. It might also be useful if one
> thinks about something like VR compositors, where precise timing control
> could help for some of the tricks ("time warping" iirc?) they use to
> hide/cope with latency from head tracking -> display.
>
> It would be nice if the kernel could help compositors which would
> implement presentation_queue or similar to be robust/precise in face of
> future stuff like Freesync, or of added delays due to Optimus/Prime
> hybrid-graphics setups. If we wanted to synchronize presentation of
> multiple displays in a Freesync type display setup, absolute target
> times could also be helpful.
I agree with all of this though.
I'd like to add that the X11 Present extension specification already
includes support for specifying a target time instead of a target
refresh cycle. This isn't implemented yet though, but it should be
relatively straightforward to implement using the kind of kernel API you
describe.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[Bug 97362] Low performance after suspend on RX 480
https://bugs.freedesktop.org/show_bug.cgi?id=97362 Bug ID: 97362 Summary: Low performance after suspend on RX 480 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: haagch at frickel.club Created attachment 125811 --> https://bugs.freedesktop.org/attachment.cgi?id=125811&action=edit dmesg 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Polaris10] (rev c7) Tried on vanilla Linux 4.7 and 4.8-rc2 with the async pageflip commit reverted. I'm testing with a very simple directx9 application (without nine) because the impact is extremely obvious with wine: http://www.codesampler.com/dx9src/dx9src_1.htm#dx9_initialization Before suspending it runs with 5000+ FPS, after suspending it runs with <1000. Also, if you keep the mouse pointer over the window moving, it will have a very small performance drop before suspending and a huuuge performance drop after suspending. I looked at the powerplay values in sysfs while that application is running in wine and before suspend, pcie is 0: 2.5GB, x8 1: 8.0GB, x16 * and sclk is 0: 300Mhz 1: 608Mhz 2: 910Mhz 3: 1077Mhz 4: 1145Mhz 5: 1191Mhz 6: 1236Mhz 7: 1288Mhz * after suspend it's pcie 0: 2.5GB, x8 * 1: 8.0GB, x16 and sclk 0: 300Mhz 1: 608Mhz * 2: 910Mhz 3: 1077Mhz 4: 1145Mhz 5: 1191Mhz 6: 1236Mhz 7: 1288Mhz mclk is 0: 300Mhz 1: 2000Mhz * in both cases. I then tried echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level and the sclk clock goes to max and pcie goes to 16x again, but the performance of the application does NOT increase so it looks like the low clocks are a symptom of whatever causes low performance. dmesg from 4.8-rc2 attached, shows some errors: [ 574.369317] failed to send message 5e ret is 0 [ 574.369317] [drm:amdgpu_vce_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 12 test failed [ 574.369317] [drm:amdgpu_resume [amdgpu]] *ERROR* resume of IP block failed -110 [ 574.369317] [drm:amdgpu_resume_kms [amdgpu]] *ERROR* amdgpu_resume failed (-110). -- 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/20160816/9f5f67ed/attachment.html>
rst htmldocs on kernel.org
Hi Jonathan, [+cc Konstantin] On Mon, Aug 15, 2016 at 04:21:15PM -0600, Jonathan Corbet wrote: > On Thu, 11 Aug 2016 21:13:29 +0200 Lukas Wunner wrote: > > not sure if this is already on your radar or if you're at all the > > right person to contact, but I just noticed that the gpu htmldocs > > are gone from https://www.kernel.org/doc/htmldocs/gpu/ > > > > Actually all the rst-formatted docs are missing. It would be great > > if they could be reinstated so as to fix all the now dangling > > hyperlinks out there... > > I agree it would be good to get the new docs there. Doing so in a way > that avoids breaking links could prove hard, though. > > I've (finally) sent off a note to Konstantin to see what can be done. It occured to me only after sending you the above e-mail that I should rather have e-mailed webmaster at kernel.org, apologies for bothering you with this. As for broken links, it's probably sufficient to just make sure that the above-quoted top level URL is functioning. This may be as simple as an "apt-get install python-sphinx python-sphinx-rtd-theme" on the machine generating the docs, assuming it's Debian, and/or copying the results to the appropriate htdocs folder. Thanks, Lukas
[PATCH V5 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
Hi, On 08/09/2016 10:11 PM, Peter Senna Tschudin wrote: > Add a driver that create a drm_bridge and a drm_connector for the LVDS > to DP++ display bridge of the GE B850v3. > > There are two physical bridges on the video signal pipeline: a > STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and > firmware made it complicated for this binding to comprise two device > tree nodes, as the design goal is to configure both bridges based on > the LVDS signal, which leave the driver powerless to control the video > processing pipeline. The two bridges behaves as a single bridge, and > the driver is only needed for telling the host about EDID / HPD, and > for giving the host powers to ack interrupts. The video signal pipeline > is as follows: > >Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output > I'd commented on an earlier revision (v2) of this patch, but hadn't got a response on it. Pasting the query again: Are these two chips always expected to be used together? I don't think it's right to pair up two encoder chips into one driver just for one board. Is one device @0x72 and other @0x73? Or is only one of them an i2c slave? What's preventing us to create these as two different bridge drivers? The drm framework allows us to daisy chain encoder bridges. The only problem I see is that we don't have a clear-cut way to tell the bridge driver whether we want it to create a connector for us or not. Because, it looks like both can potentially create connectors. This isn't a big problem either if we have DT. We just need to check whether our output port is connected to another bridge or a connector. Thanks, Archit > Cc: Martyn Welch > Cc: Martin Donnelly > Cc: Daniel Vetter > Cc: Enric Balletbo i Serra > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Fabio Estevam > CC: David Airlie > CC: Thierry Reding > CC: Thierry Reding > Reviewed-by: Enric Balletbo > Signed-off-by: Peter Senna Tschudin > --- > Changes from V4: > - Check the output of the first call to i2c_smbus_write_word_data() and > return > it's error code for failing gracefully on i2c issues > - Renamed the i2c_driver.name from "ge,b850v3-lvds-dp" to "b850v3-lvds-dp" > to > remove the comma from the driver name > > Changes from V3: > - 3/4 instead of 4/5 > - Tested on next-20160804 > > Changes from V2: > - Made it atomic to be applied on next-20160729 on top of Liu Ying changes > that made imx-ldb atomic > > Changes from V1: > - New commit message > - Removed 3 empty entry points > - Removed memory leak from ge_b850v3_lvds_dp_get_modes() > - Added a lock for mode setting > - Removed a few blank lines > - Changed the order at Makefile and Kconfig > > MAINTAINERS| 8 + > drivers/gpu/drm/bridge/Kconfig | 11 + > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 405 > + > 4 files changed, 425 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a306795..e8d106a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5142,6 +5142,14 @@ W: https://linuxtv.org > S: Maintained > F: drivers/media/radio/radio-gemtek* > > +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE > +M: Peter Senna Tschudin > +M: Martin Donnelly > +M: Martyn Welch > +S: Maintained > +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c > +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt > + > GENERIC GPIO I2C DRIVER > M: Haavard Skinnemoen > S: Supported > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index b590e67..b4b70fb 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO > Designware HDMI block. This is used in conjunction with > the i.MX6 HDMI driver. > > +config DRM_GE_B850V3_LVDS_DP > + tristate "GE B850v3 LVDS to DP++ display bridge" > + depends on OF > + select DRM_KMS_HELPER > + select DRM_PANEL > + ---help--- > + This is a driver for the display bridge of > + GE B850v3 that convert dual channel LVDS > + to DP++. This is used with the i.MX6 imx-ldb > + driver. > + > config DRM_NXP_PTN3460 > tristate "NXP PTN3460 DP/LVDS bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index efdb07e..b9606f3 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o > obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o > +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > obj-$(CONFIG_DRM_P
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
Hi Michel and Daniel, I just tryed Michel's advice: return 0 in vblank_get_counter, and set dev->max_vblank_count = 0 , and found the adev->ddev->vblank[crtc].count also can increase which makes the 3D app with vsync can work properly as well. But I don't know the principle. Anyway I will take Michel's advice about vblank count, and send a patch later. Best Wishes, Emily Deng > -Original Message- > From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of > Deng, Emily > Sent: Tuesday, August 16, 2016 5:14 PM > To: Michel Dänzer ; Daniel Vetter > > Cc: dri-devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org > Subject: RE: [PATCH] drm/amdgpu: For virtual_display feature, define a > variable > for vblank count of cpu vsync timer. > > Hi Michel and Daniel, > Return the fake vblank count or return 0 in vblank_get_counter is only > the > virtual display feature's behavior, and the virtual display feature need to be > enabled by set module parameter, so won't affect normal case. And I think the > vblank counter will be increased every time when the vsync timer interrupt > occurs in virtual display feature is reasonable, so that the 3D app about > vblank > count could work normally. For the time stamp could be set to limitations for > virtual display feature. > > Best Wishes, > Emily Deng > > -Original Message- > > From: Michel Dänzer [mailto:michel at daenzer.net] > > Sent: Tuesday, August 16, 2016 3:18 PM > > To: Deng, Emily > > Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a > > variable for vblank count of cpu vsync timer. > > > > On 16/08/16 04:00 PM, Deng, Emily wrote: > > >> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On > > >> Behalf Of Michel D?nzer > > >> Sent: Tuesday, August 16, 2016 2:43 PM On 16/08/16 03:28 PM, Deng, > > >> Emily wrote: > > From: Michel Dänzer [mailto:michel at daenzer.net] > > Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, > > Deng, Emily wrote: > > > Hi Michel, Thanks, I still couldn't see the issue that use a > > > variable to calculate the vblank count when vsync timer > > > interrupt occurs. I just think it only emulates the hardware > > > behavior. And the code change will only in virtual display files > > > which won't touch drm layer. I incline to not modify the code in > > > drm layer or amdgpu other codes, because it may lead to other issues . > > > > I see it basically the other way around: We are currently > > pretending to the DRM core code that we have a reliable hardware > > vblank counter and timing even in the virtual DCE case, when we > > really don't. We should stop pretending and instead communicate > > the lack of these hardware facilities in the virtual DCE case as > > intended, otherwise we'll > > >> probably run into issues sooner or later. > > > > >>> [[EmilyD]] Hi Michel, yes, you are right, we are pretending a > > >>> hardware vblank counter in virtual DCE case to drm layer. But can > > >>> you specific some > > >> cases that we must communicate with drm layer that we don't have > > >> the vblank counter. > > >> > > >> I described all the necessary steps (that I know of; there may be > > >> more) in https://lists.freedesktop.org/archives/amd-gfx/2016- > > August/001342.html . > > >> > > > [[EmilyD]] Hi Michel, I means can you detail the reasons or cases > > > that we should communicate with drm layer when don't have the vblank > > > counter > > instead of pretending a hardware vblank counter in virtual DCE case. > > > > The DRM core code expects the get_vblank_counter hook to use a > > reliable hardware counter. If that is not the case, it should always return > > 0. > > > > Similarly, drm_calc_vbltimestamp_from_scanoutpos expects the > > get_scanout_position hook to return accurate scanout position values > > based on reliable hardware registers. > > > > If we pretend to return accurate values from these when we actually > > can't, the DRM core code may provide incorrect vblank counter / > > timestamp values to userspace, or worse. > > > > Those are just off the top of my head, there may be more along the same > > lines. > > > > > > -- > > Earthling Michel Dänzer | http://www.amd.com > > Libre software enthusiast | Mesa and X developer > ___ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #10 from Jimi --- Sorry, autocorrect typos. Thing #1 is supposed to say that it's going to be a problem when I'm able to successfully unbind my card from amdgpu and will need to be able to rescan PCI devices without it auto-binding to amdgpu, because I'll want to bind it to vfio-pci. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #9 from Jimi --- Over at the X bug report, I've figured out that when X has AutoAddGPU turned off, it doesnt crash (meaning that bug is not related to this bug), however, the card is still automatically bound to amdgpu before I can bind it, which means 2 things: 1. That's going to be a problem when I'm able to successfully unbinding my card from amdgpu and will need to be able to respond PCI devices without it auto-binding to amdgpu, because I'll want to bind it to vfio-pci. 2. That part of the X bug is actually its own bug, which makes sense, because the card would immediately auto-bind to amdgpu if I tested things without X running. So, as far as this bug report is concerned, we actually have 2 bugs going on: the card can't be unbound, and the card is automatically bound on a rescan, stopping the user from having a choice in which driver it gets bound to. I think these 2 issues just may be related. Maybe they even have the same cause? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v4] drm: Introduce DRM_DEV_* log messages
On Tue, Aug 16, 2016 at 5:28 AM, Eric Engestrom
wrote:
> On Mon, Aug 15, 2016 at 04:18:04PM -0700, Sean Paul wrote:
>> This patch consolidates all the various log functions/macros into
>> one uber function, drm_log. It also introduces some new DRM_DEV_*
>> variants that print the device name to delineate multiple devices
>> of the same type.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2:
>> - Use dev_printk for the dev variant (Chris Wilson)
>>
>> Changes in v3:
>> - Rename drm_log to drm_dev_printk (Chris Wilson)
>> - Break out drm_printk from drm_dev_printk to reduce
>> image growth due to passing NULL around (Chris Wilson)
>>
>> Changes in v4:
>> - Pull format string out into #define (Eric Engestrom)
>>
>>
>> drivers/gpu/drm/drm_drv.c | 27 ++---
>> include/drm/drmP.h| 140
>> +++---
>> 2 files changed, 103 insertions(+), 64 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 57ce973..a7f6282 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -63,37 +63,48 @@ static struct idr drm_minors_idr;
>>
>> static struct dentry *drm_debugfs_root;
>>
>> -void drm_err(const char *format, ...)
>> +#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
>> +
>> +void drm_dev_printk(const struct device *dev, const char *level,
>> + unsigned int category, const char *function_name,
>> + const char *prefix, const char *format, ...)
>> {
>> struct va_format vaf;
>> va_list args;
>>
>> - va_start(args, format);
>> + if (category != DRM_UT_NONE && !(drm_debug & category))
>> + return;
>>
>> + va_start(args, format);
>> vaf.fmt = format;
>> vaf.va = &args;
>>
>> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
>> -__builtin_return_address(0), &vaf);
>> + dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
>> +&vaf);
>>
>> va_end(args);
>> }
>> -EXPORT_SYMBOL(drm_err);
>> +EXPORT_SYMBOL(drm_dev_printk);
>>
>> -void drm_ut_debug_printk(const char *function_name, const char *format, ...)
>> +void drm_printk(const char *level, unsigned int category,
>> + const char *function_name, const char *prefix,
>> + const char *format, ...)
>> {
>> struct va_format vaf;
>> va_list args;
>>
>> + if (category != DRM_UT_NONE && !(drm_debug & category))
>> + return;
>> +
>> va_start(args, format);
>> vaf.fmt = format;
>> vaf.va = &args;
>>
>> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
>> + printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
>>
>> va_end(args);
>> }
>> -EXPORT_SYMBOL(drm_ut_debug_printk);
>> +EXPORT_SYMBOL(drm_printk);
>>
>> /*
>> * DRM Minors
>> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
>> index f8e87fd..94eb138 100644
>> --- a/include/drm/drmP.h
>> +++ b/include/drm/drmP.h
>> @@ -127,6 +127,7 @@ struct dma_buf_attachment;
>> * run-time by echoing the debug value in its sysfs node:
>> * # echo 0xf > /sys/module/drm/parameters/debug
>> */
>> +#define DRM_UT_NONE 0x00
>> #define DRM_UT_CORE 0x01
>> #define DRM_UT_DRIVER0x02
>> #define DRM_UT_KMS 0x04
>> @@ -134,11 +135,15 @@ struct dma_buf_attachment;
>> #define DRM_UT_ATOMIC0x10
>> #define DRM_UT_VBL 0x20
>>
>> -extern __printf(2, 3)
>> -void drm_ut_debug_printk(const char *function_name,
>> - const char *format, ...);
>> -extern __printf(1, 2)
>> -void drm_err(const char *format, ...);
>> +extern __printf(6, 7)
>> +void drm_dev_printk(const struct device *dev, const char *level,
>> + unsigned int category, const char *function_name,
>> + const char *prefix, const char *format, ...);
>> +
>> +extern __printf(5, 6)
>> +void drm_printk(const char *level, unsigned int category,
>> + const char *function_name, const char *prefix,
>> + const char *format, ...);
>>
>> /***/
>> /** \name DRM template customization defaults */
>> @@ -169,8 +174,12 @@ void drm_err(const char *format, ...);
>> * \param fmt printf() like format string.
>> * \param arg arguments
>> */
>> -#define DRM_ERROR(fmt, ...) \
>> - drm_err(fmt, ##__VA_ARGS__)
>> +#define DRM_DEV_ERROR(dev, fmt, ...) \
>> + drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
>> +fmt, ##__VA_ARGS__)
>> +#define DRM_ERROR(fmt, ...) \
>> + drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
>> +##__VA_ARGS__)
>>
>> /**
>> * Rate limited error output. Like DRM_ERROR() but won't flood t
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On Tue, Aug 16, 2016 at 03:43:07PM +0900, Michel Dänzer wrote: > On 16/08/16 03:28 PM, Deng, Emily wrote: > >> From: Michel Dänzer [mailto:michel at daenzer.net] > >> Sent: Tuesday, August 16, 2016 12:01 PM > >> On 16/08/16 12:49 PM, Deng, Emily wrote: > >>> Hi Michel, Thanks, I still couldn't see the issue that use a variable > >>> to calculate the vblank count when vsync timer interrupt occurs. I > >>> just think it only emulates the hardware behavior. And the code change > >>> will only in virtual display files which won't touch drm layer. I > >>> incline to not modify the code in drm layer or amdgpu other codes, > >>> because it may lead to other issues . > >> > >> I see it basically the other way around: We are currently pretending to > >> the DRM > >> core code that we have a reliable hardware vblank counter and timing even > >> in > >> the virtual DCE case, when we really don't. We should stop pretending and > >> instead communicate the lack of these hardware facilities in the virtual > >> DCE case > >> as intended, otherwise we'll probably run into issues sooner or later. Yes please don't lie to the vblank core. In the future we might depend more on this, and that might lead to surprises. > > [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware > > vblank counter in virtual DCE case to drm > > layer. But can you specific some cases that we must communicate with drm > > layer that we don't have the vblank counter. > > I described all the necessary steps (that I know of; there may be more) > in https://lists.freedesktop.org/archives/amd-gfx/2016-August/001342.html . Yeah I missed the accurate timestamp part, since on i915 on gen2 we can still do that part. Your todo list looks accurate from what I can tell. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
Hi Michel and Daniel, Return the fake vblank count or return 0 in vblank_get_counter is only the virtual display feature's behavior, and the virtual display feature need to be enabled by set module parameter, so won't affect normal case. And I think the vblank counter will be increased every time when the vsync timer interrupt occurs in virtual display feature is reasonable, so that the 3D app about vblank count could work normally. For the time stamp could be set to limitations for virtual display feature. Best Wishes, Emily Deng > -Original Message- > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Tuesday, August 16, 2016 3:18 PM > To: Deng, Emily > Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a > variable > for vblank count of cpu vsync timer. > > On 16/08/16 04:00 PM, Deng, Emily wrote: > >> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On > >> Behalf Of Michel D?nzer > >> Sent: Tuesday, August 16, 2016 2:43 PM On 16/08/16 03:28 PM, Deng, > >> Emily wrote: > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, Deng, > Emily wrote: > > Hi Michel, Thanks, I still couldn't see the issue that use a > > variable to calculate the vblank count when vsync timer interrupt > > occurs. I just think it only emulates the hardware behavior. And > > the code change will only in virtual display files which won't > > touch drm layer. I incline to not modify the code in drm layer or > > amdgpu other codes, because it may lead to other issues . > > I see it basically the other way around: We are currently > pretending to the DRM core code that we have a reliable hardware > vblank counter and timing even in the virtual DCE case, when we > really don't. We should stop pretending and instead communicate the > lack of these hardware facilities in the virtual DCE case as > intended, otherwise we'll > >> probably run into issues sooner or later. > > >>> [[EmilyD]] Hi Michel, yes, you are right, we are pretending a > >>> hardware vblank counter in virtual DCE case to drm layer. But can > >>> you specific some > >> cases that we must communicate with drm layer that we don't have the > >> vblank counter. > >> > >> I described all the necessary steps (that I know of; there may be > >> more) in https://lists.freedesktop.org/archives/amd-gfx/2016- > August/001342.html . > >> > > [[EmilyD]] Hi Michel, I means can you detail the reasons or cases that > > we should communicate with drm layer when don't have the vblank counter > instead of pretending a hardware vblank counter in virtual DCE case. > > The DRM core code expects the get_vblank_counter hook to use a reliable > hardware counter. If that is not the case, it should always return 0. > > Similarly, drm_calc_vbltimestamp_from_scanoutpos expects the > get_scanout_position hook to return accurate scanout position values based on > reliable hardware registers. > > If we pretend to return accurate values from these when we actually can't, the > DRM core code may provide incorrect vblank counter / timestamp values to > userspace, or worse. > > Those are just off the top of my head, there may be more along the same lines. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer
[PATCH 12/21] drm/doc: Update drm_framebuffer docs
On Fri, Aug 12, 2016 at 1:48 PM, Daniel Vetter wrote: > - Move the intro section into a DOC comment, and update it slightly. > - kernel-doc for struct drm_framebuffer! > > v2: > - Copypaste fail (Sean). > - Explain the linear @offsets clearer (Ville). > > Cc: Sean Paul > Cc: Ville Syrjälä > Signed-off-by: Daniel Vetter Reviewed-by: Sean Paul > --- > Documentation/gpu/drm-kms.rst | 26 +- > drivers/gpu/drm/drm_framebuffer.c | 35 + > include/drm/drm_framebuffer.h | 106 > +- > 3 files changed, 130 insertions(+), 37 deletions(-) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 8264a88a8695..d244e03658cc 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -39,30 +39,8 @@ Atomic Mode Setting Function Reference > Frame Buffer Abstraction > > > -Frame buffers are abstract memory objects that provide a source of > -pixels to scanout to a CRTC. Applications explicitly request the > -creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls > -and receive an opaque handle that can be passed to the KMS CRTC control, > -plane configuration and page flip functions. > - > -Frame buffers rely on the underneath memory manager for low-level memory > -operations. When creating a frame buffer applications pass a memory > -handle (or a list of memory handles for multi-planar formats) through > -the ``drm_mode_fb_cmd2`` argument. For drivers using GEM as their > -userspace buffer management interface this would be a GEM handle. > -Drivers are however free to use their own backing storage object > -handles, e.g. vmwgfx directly exposes special TTM handles to userspace > -and so expects TTM handles in the create ioctl and not GEM handles. > - > -The lifetime of a drm framebuffer is controlled with a reference count, > -drivers can grab additional references with > -:c:func:`drm_framebuffer_reference()`and drop them again with > -:c:func:`drm_framebuffer_unreference()`. For driver-private > -framebuffers for which the last reference is never dropped (e.g. for the > -fbdev framebuffer when the struct :c:type:`struct drm_framebuffer > -` is embedded into the fbdev helper struct) > -drivers can manually clean up a framebuffer at module unload time with > -:c:func:`drm_framebuffer_unregister_private()`. > +.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c > + :doc: overview > > Frame Buffer Functions Reference > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > b/drivers/gpu/drm/drm_framebuffer.c > index 19478a25ac20..34e3c4acbc8a 100644 > --- a/drivers/gpu/drm/drm_framebuffer.c > +++ b/drivers/gpu/drm/drm_framebuffer.c > @@ -28,6 +28,41 @@ > #include "drm_crtc_internal.h" > > /** > + * DOC: overview > + * > + * Frame buffers are abstract memory objects that provide a source of pixels > to > + * scanout to a CRTC. Applications explicitly request the creation of frame > + * buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque > + * handle that can be passed to the KMS CRTC control, plane configuration and > + * page flip functions. > + * > + * Frame buffers rely on the underlying memory manager for allocating backing > + * storage. When creating a frame buffer applications pass a memory handle > + * (or a list of memory handles for multi-planar formats) through the > + * struct &drm_mode_fb_cmd2 argument. For drivers using GEM as their > userspace > + * buffer management interface this would be a GEM handle. Drivers are > however > + * free to use their own backing storage object handles, e.g. vmwgfx directly > + * exposes special TTM handles to userspace and so expects TTM handles in the > + * create ioctl and not GEM handles. > + * > + * Framebuffers are tracked with struct &drm_framebuffer. They are published > + * using drm_framebuffer_init() - after calling that function userspace can > use > + * and access the framebuffer object. The helper function > + * drm_helper_mode_fill_fb_struct() can be used to pre-fill the required > + * metadata fields. > + * > + * The lifetime of a drm framebuffer is controlled with a reference count, > + * drivers can grab additional references with drm_framebuffer_reference() > and > + * drop them again with drm_framebuffer_unreference(). For driver-private > + * framebuffers for which the last reference is never dropped (e.g. for the > + * fbdev framebuffer when the struct struct &drm_framebuffer is embedded into > + * the fbdev helper struct) drivers can manually clean up a framebuffer at > + * module unload time with drm_framebuffer_unregister_private(). But doing > this > + * is not recommended, and it's better to have a normal free-standing struct > + * &drm_framebuffer. > + */ > + > +/** > * drm_mode_addfb - add an FB to the graphics configuration > * @dev: drm device for the ioctl > * @data: data pointer for the ioctl > diff --git a
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
> -Original Message- > From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of > Michel D?nzer > Sent: Tuesday, August 16, 2016 2:43 PM > To: Deng, Emily > Cc: dri-devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a > variable > for vblank count of cpu vsync timer. > > On 16/08/16 03:28 PM, Deng, Emily wrote: > >> From: Michel Dänzer [mailto:michel at daenzer.net] > >> Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, Deng, > >> Emily wrote: > >>> Hi Michel, Thanks, I still couldn't see the issue that use a > >>> variable to calculate the vblank count when vsync timer interrupt > >>> occurs. I just think it only emulates the hardware behavior. And the > >>> code change will only in virtual display files which won't touch drm > >>> layer. I incline to not modify the code in drm layer or amdgpu other > >>> codes, because it may lead to other issues . > >> > >> I see it basically the other way around: We are currently pretending > >> to the DRM core code that we have a reliable hardware vblank counter > >> and timing even in the virtual DCE case, when we really don't. We > >> should stop pretending and instead communicate the lack of these > >> hardware facilities in the virtual DCE case as intended, otherwise we'll > probably run into issues sooner or later. > >> > > [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware > > vblank counter in virtual DCE case to drm layer. But can you specific some > cases that we must communicate with drm layer that we don't have the vblank > counter. > > I described all the necessary steps (that I know of; there may be more) in > https://lists.freedesktop.org/archives/amd-gfx/2016-August/001342.html . > [[EmilyD]] Hi Michel, I means can you detail the reasons or cases that we should communicate with drm layer when don't have the vblank counter instead of pretending a hardware vblank counter in virtual DCE case. > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > ___ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 01/21] drm/doc: Fix more kerneldoc/sphinx warnings
> struct guc_css_header {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b506b04d..194eebb2f9d7 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1197,7 +1197,7 @@ struct drm_encoder_funcs {
> * @head: list management
> * @base: base KMS object
> * @name: human readable name, can be overwritten by the driver
> - * @encoder_type: one of the %DRM_MODE_ENCODER_ types in drm_mode.h
> + * @encoder_type: one of the DRM_MODE_ENCODER_ types in drm_mode.h
> * @possible_crtcs: bitmask of potential CRTC bindings
> * @possible_clones: bitmask of potential sibling encoders for cloning
> * @crtc: currently bound CRTC
> @@ -1250,7 +1250,7 @@ struct drm_encoder {
> * @head: list management
> * @base: base KMS object
> * @name: human readable name, can be overwritten by the driver
> - * @connector_type: one of the %DRM_MODE_CONNECTOR_ types from
drm_mode.h
> + * @connector_type: one of the DRM_MODE_CONNECTOR_ types from
drm_mode.h
> * @connector_type_id: index into connector type enum
> * @interlace_allowed: can this connector handle interlaced modes?
> * @doublescan_allowed: can this connector handle doublescan?
> @@ -1263,11 +1263,11 @@ struct drm_encoder {
> * @funcs: connector control functions
> * @edid_blob_ptr: DRM property containing EDID if present
> * @properties: property tracking for this connector
> - * @polled: a %DRM_CONNECTOR_POLL_ value for core driven polling
> + * @polled: a DRM_CONNECTOR_POLL_ value for core driven polling
> * @dpms: current dpms state
> * @helper_private: mid-layer private data
> * @cmdline_mode: mode line parsed from the kernel cmdline for this
connector
> - * @force: a %DRM_FORCE_ state for forced mode sets
> + * @force: a DRM_FORCE_ state for forced mode sets
> * @override_edid: has the EDID been overwritten through debugfs for
testing?
> * @encoder_ids: valid encoders for this connector
> * @encoder: encoder driving this connector, if any
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index fca1cd1b9c26..9f63736e6163 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -210,8 +210,8 @@ drm_gem_object_reference(struct drm_gem_object *obj)
> * drm_gem_object_unreference_unlocked().
> *
> * Drivers should never call this directly in their code. Instead they
should
> - * wrap it up into a driver_gem_object_unreference(struct
driver_gem_object
> - * *obj) wrapper function, and use that. Shared code should never call
this, to
> + * wrap it up into a ``driver_gem_object_unreference(struct
driver_gem_object
> + * *obj)`` wrapper function, and use that. Shared code should never call
this, to
> * avoid breaking drivers by accident which still depend upon
dev->struct_mutex
> * locking.
> */
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160816/a461c39f/attachment-0001.html>
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
> -Original Message- > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Tuesday, August 16, 2016 12:01 PM > To: Deng, Emily > Cc: dri-devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a > variable > for vblank count of cpu vsync timer. > > On 16/08/16 12:49 PM, Deng, Emily wrote: > > Hi Michel, Thanks, I still couldn't see the issue that use a variable > > to calculate the vblank count when vsync timer interrupt occurs. I > > just think it only emulates the hardware behavior. And the code change > > will only in virtual display files which won't touch drm layer. I > > incline to not modify the code in drm layer or amdgpu other codes, > > because it may lead to other issues . > > I see it basically the other way around: We are currently pretending to the > DRM > core code that we have a reliable hardware vblank counter and timing even in > the virtual DCE case, when we really don't. We should stop pretending and > instead communicate the lack of these hardware facilities in the virtual DCE > case > as intended, otherwise we'll probably run into issues sooner or later. > [[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware vblank counter in virtual DCE case to drm layer. But can you specific some cases that we must communicate with drm layer that we don't have the vblank counter. > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer
[Bug 97260] [bisected] R9 290 low performance in Linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97260 --- Comment #19 from Michel Dänzer --- BTW, there are some potential workarounds: * Disable DRI3 for affected games with the environment variable LIBGL_DRI3_DISABLE=1 * Enable sync-to-vblank in affected applications, or force it with vblank_mode=3 -- 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/20160816/d9848207/attachment.html>
[Bug 97260] [bisected] R9 290 low performance in Linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97260 --- Comment #18 from Michel Dänzer --- Created attachment 125808 --> https://bugs.freedesktop.org/attachment.cgi?id=125808&action=edit radeon: Add some page flip debugging output Well, that's a surprising result of the bisection. I can imagine two possible causes, or possibly some combination thereof: * The processing of asynchronous flips or the corresponding completion interrupts is delayed for some reason * Using flips instead of blits for buffer swaps lowers the load on the GPU 3D engine, so the SMU doesn't switch to higher clocks The attached debugging patch should give us more information about the former. With it applied, run the following while an affected application is running in fullscreen: sudo sh -c 'echo 2 >/sys/module/drm/parameters/debug'; sleep 1; sudo sh -c 'echo 0 >/sys/module/drm/parameters/debug' Then attach the resulting dmesg output. BTW, does the problem still happen with Alex's current drm-next-4.9-wip branch? -- 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/20160816/7ec0c0a0/attachment.html>
[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
Hi Michel, Thanks, I still couldn't see the issue that use a variable to calculate the vblank count when vsync timer interrupt occurs. I just think it only emulates the hardware behavior. And the code change will only in virtual display files which won't touch drm layer. I incline to not modify the code in drm layer or amdgpu other codes, because it may lead to other issues . Best Wishes, Emily Deng > -Original Message- > From: Michel Dänzer [mailto:michel at daenzer.net] > Sent: Tuesday, August 16, 2016 11:12 AM > To: Deng, Emily > Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a > variable > for vblank count of cpu vsync timer. > > On 15/08/16 03:45 PM, Deng, Emily wrote: > >> From: Michel Dänzer [mailto:michel at daenzer.net] > >> Sent: Monday, August 15, 2016 9:46 AM On 11/08/16 12:46 PM, Emily > >> Deng wrote: > >>> The adev->ddev->vblank[crtc].count couldn't be used here, so define > >>> another variable to compute the vblank count. > >>> > >>> Signed-off-by: Emily Deng > >> > >> [...] > >> > >>> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c > >>> b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c > >>> index 2ce5f90..d616ab9 100644 > >>> --- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c > >>> +++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c > >>> @@ -58,7 +58,7 @@ static u32 dce_virtual_vblank_get_counter(struct > >> amdgpu_device *adev, int crtc) > >>> if (crtc >= adev->mode_info.num_crtc) > >>> return 0; > >>> else > >>> - return adev->ddev->vblank[crtc].count; > >>> + return adev->mode_info.timer_vblank_count; > >>> } > >> > >> AFAIK the vblank_get_counter hook is supposed to always return 0 when > >> there's no hardware frame counter which can be used. That's what > >> drm_vblank_no_hw_counter was created for. > >> > > [[EmilyD]] Sorry, I don't know much about drm_vblank_no_hw_counter, > > can it support vsync when return to 0? > > That's its purpose. BTW, I realized in the meantime that we can't use > drm_vblank_no_hw_counter directly, because there's a single struct > drm_driver used by all amdgpu driver instances. > > > >> You mentioned internally that you ran into trouble when trying this though. > >> Please provide more information about that, e.g.: Which base kernel > >> version did you test it with? What values did the > >> DRM_IOCTL_WAIT_VBLANK ioctl return to userspace? ... > >> > > [[EmilyD]] I run the driver on kernel version 4.6, and run glxgears > > with vsync enabled. It is hard to detail the issue, I will try my best to > description the issue I found. > > After I double checked, it is not segment fault in libGL.so when run > > glxgears with vsync, but the glxgears will be stucked in waiting for > > the before swap buffers to complete. This is because when enable > > vsync, every time swap buffers, the DDX driver will call > > DRM_IOCTL_WAIT_VBLANK to queue the vblank event, and the > vbl.request.sequence will be set to current_vblank_count + swap_interval. Then > in kernel driver, when timer interrupt occurs, it will call > drm_handle_vblank_events, it will call drm_vblank_count_and_time to get > current seq, and only seq >= vbl.request.sequence, then will call > send_vblank_event. So it will never call send_vblank_event. > > For example, the DDX driver call DRM_IOCTL_WAIT_VBLANK , then kernel > > driver will call drm_queue_vblank_event, and current vblank_count is 1 > > (As we only return 0 in vblank_get_counter, so the vblank_count will > > never change except calling drm_reset_vblank_timestamp which will make > > adev->ddev->vblank[crtc].count++), and swap_interval is 1, then > > adev->ddev->vbl.request.sequence will be 2, but the > > adev->ddev->drm_vblank_count_and_time will always > > return 1 except calling drm_reset_vblank_timestamp(The function > > drm_reset_vblank_timestamp will only be called in > drm_vblank_post_modeset and drm_vblank_on ), so the send_vblank_event > will never be called, and swap buffers won't complete, so the glxgears will be > stucked. > > Looking at the drm_update_vblank_count() code, you also need to do the > following in the virtual DCE case: > > * Set dev->max_vblank_count = 0 > * Make amdgpu_get_vblank_timestamp_kms either return values based on > when the virtual vblank interrupt timer last fired, or just return a > negative error code immediately, instead of calling > drm_calc_vbltimestamp_from_scanoutpos > * Make amdgpu_get_vblank_counter_kms take the else path (or just return > 0 immediately), not run any of the scanout position related code > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer
[PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2
Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland.
Wrt. having a new pageflip parameter struct, i wonder if it wouldn't
make sense to then already prepare some space in it for specifying an
absolute target time, e.g., in u64 microseconds? Or make this part of
the atomic pageflip framework?
In Wayland we now have the presentation_feedback extension (maybe it got
a new name?), which is great to get feedback when and how presentation
was completed, essentially the equivalent of X11's GLX_INTEL_swap_events
+ some useful extra info / the feedback half of OML_sync_control.
That was supposed to be complemented by a presentation_queue extension
which would provide the other half of OML_sync_control, the part where
an app can tell the compositor when and how to present surface updates.
I remember that a year ago inclusion of that extension was blocked on
some other more urgent important blocker bugs? Did this make progress?
For timing sensitive applications such an extension is even more
important in a wayland world than under X11. On X11 most desktops allow
unredirecting fullscreen windows, so an app can drive the flip timing
rather direct. At least on Weston as i remember it from my last tests a
year ago, that wasn't possible, and an app that doesn't want to present
at each video refresh, but at specific target times had to guess what
the specific compositors scheduling strategy might be and then "play
games" wrt. to timing surface commit's to trick the compositor into sort
of doing the right thing - very fragile.
Anyway, the idea of presentation_queue was to specify the requested time
of presentation as actual time, not as a target vblank count. This
because applications that care about precise presentation timing, like
my kind of neuroscience/medical visual stimulation software, or also
video players, or e.g., at least the VDPAU video presentation api
"think" in absolute time, not in refresh cycles. Also a target vblank
count for presentation is less meaningful than a target time for things
like variable framerate displays/adaptive sync, or displays which don't
have a classic refresh cycle at all. It might also be useful if one
thinks about something like VR compositors, where precise timing control
could help for some of the tricks ("time warping" iirc?) they use to
hide/cope with latency from head tracking -> display.
It would be nice if the kernel could help compositors which would
implement presentation_queue or similar to be robust/precise in face of
future stuff like Freesync, or of added delays due to Optimus/Prime
hybrid-graphics setups. If we wanted to synchronize presentation of
multiple displays in a Freesync type display setup, absolute target
times could also be helpful.
-mario
On 08/08/2016 09:23 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> These flags allow userspace to explicitly specify the target vertical
> blank period when a flip should take effect.
>
> v2:
> * Add new struct drm_mode_crtc_page_flip_target instead of modifying
> struct drm_mode_crtc_page_flip, to make sure all existing userspace
> code keeps compiling (Daniel Vetter)
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Michel Dänzer
> ---
> drivers/gpu/drm/drm_crtc.c | 48
> ++---
> drivers/gpu/drm/drm_ioctl.c | 8
> include/uapi/drm/drm.h | 1 +
> include/uapi/drm/drm_mode.h | 39 +---
> 4 files changed, 86 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d6491ef..3e1a63d 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5417,15 +5417,23 @@ out:
> int drm_mode_page_flip_ioctl(struct drm_device *dev,
>void *data, struct drm_file *file_priv)
> {
> - struct drm_mode_crtc_page_flip *page_flip = data;
> + struct drm_mode_crtc_page_flip_target *page_flip = data;
> struct drm_crtc *crtc;
> struct drm_framebuffer *fb = NULL;
> struct drm_pending_vblank_event *e = NULL;
> - u32 target_vblank = 0;
> + u32 target_vblank = page_flip->sequence;
> int ret = -EINVAL;
>
> - if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
> - page_flip->reserved != 0)
> + if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS)
> + return -EINVAL;
> +
> + if (page_flip->sequence != 0 && !(page_flip->flags &
> DRM_MODE_PAGE_FLIP_TARGET))
> + return -EINVAL;
> +
> + /* Only one of the DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags
> + * can be specified
> + */
> + if ((page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET) ==
> DRM_MODE_PAGE_FLIP_TARGET)
> return -EINVAL;
>
> if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
> !dev->mode_config.async_page_flip)
> @@ -5436,15 +5444,41 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> re
[PATCH 4/6] drm/radeon: Provide page_flip_target hook
Hi Michel,
sorry for the super-late reply, i was just catching up with all the
mails and discussions, starting in June, leading to this patch set.
Looks all pretty good.
I'll look at this radeon patch and 2/6 for amdgpu later this week when i
have a fresh brain and enough "obsessive compulsive time", to make sure
all the magic wrt. "virtually extended vblank" and the fudging logic is
fine.
I'll then also run it through my timing tests. I assume the
ati/amdgpu-ddx patches and libdrm patches in your freedesktop home are
all i need for testing?
-mario
On 08/04/2016 05:39 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Now we can program a flip during a vertical blank period, if it's the
> one targeted by the flip (or a later one). This allows simplifying
> radeon_flip_work_func considerably.
>
> Signed-off-by: Michel Dänzer
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 +
> drivers/gpu/drm/radeon/radeon_display.c | 89
> +
> 2 files changed, 25 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5633ee3..1b0dcad 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -742,6 +742,7 @@ struct radeon_flip_work {
> struct work_struct unpin_work;
> struct radeon_device*rdev;
> int crtc_id;
> + u32 target_vblank;
> uint64_tbase;
> struct drm_pending_vblank_event *event;
> struct radeon_bo*old_rbo;
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 5f1cd69..bd9d995 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -400,14 +400,13 @@ static void radeon_flip_work_func(struct work_struct
> *__work)
> struct radeon_flip_work *work =
> container_of(__work, struct radeon_flip_work, flip_work);
> struct radeon_device *rdev = work->rdev;
> + struct drm_device *dev = rdev->ddev;
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[work->crtc_id];
>
> struct drm_crtc *crtc = &radeon_crtc->base;
> unsigned long flags;
> int r;
> - int vpos, hpos, stat, min_udelay = 0;
> - unsigned repcnt = 4;
> - struct drm_vblank_crtc *vblank = &crtc->dev->vblank[work->crtc_id];
> + int vpos, hpos;
>
> down_read(&rdev->exclusive_lock);
> if (work->fence) {
> @@ -438,59 +437,25 @@ static void radeon_flip_work_func(struct work_struct
> *__work)
> work->fence = NULL;
> }
>
> + /* Wait until we're out of the vertical blank period before the one
> + * targeted by the flip
> + */
> + while (radeon_crtc->enabled &&
> +(radeon_get_crtc_scanoutpos(dev, work->crtc_id, 0,
> +&vpos, &hpos, NULL, NULL,
> +&crtc->hwmode)
> + & (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_IN_VBLANK)) ==
> +(DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_IN_VBLANK) &&
> +(int)(work->target_vblank -
> + dev->driver->get_vblank_counter(dev, work->crtc_id)) > 0)
> + usleep_range(1000, 2000);
> +
> /* We borrow the event spin lock for protecting flip_status */
> spin_lock_irqsave(&crtc->dev->event_lock, flags);
>
> /* set the proper interrupt */
> radeon_irq_kms_pflip_irq_get(rdev, radeon_crtc->crtc_id);
>
> - /* If this happens to execute within the "virtually extended" vblank
> - * interval before the start of the real vblank interval then it needs
> - * to delay programming the mmio flip until the real vblank is entered.
> - * This prevents completing a flip too early due to the way we fudge
> - * our vblank counter and vblank timestamps in order to work around the
> - * problem that the hw fires vblank interrupts before actual start of
> - * vblank (when line buffer refilling is done for a frame). It
> - * complements the fudging logic in radeon_get_crtc_scanoutpos() for
> - * timestamping and radeon_get_vblank_counter_kms() for vblank counts.
> - *
> - * In practice this won't execute very often unless on very fast
> - * machines because the time window for this to happen is very small.
> - */
> - while (radeon_crtc->enabled && --repcnt) {
> - /* GET_DISTANCE_TO_VBLANKSTART returns distance to real vblank
> - * start in hpos, and to the "fudged earlier" vblank start in
> - * vpos.
> - */
> - stat = radeon_get_crtc_scanoutpos(rdev->ddev, work->crtc_id,
> - GET_DISTANCE_TO_VBLANKSTART,
> - &vpos, &hpos, NULL, NULL,
> -
[Bug 97303] battery mode for dpm state froze
https://bugs.freedesktop.org/show_bug.cgi?id=97303 Michel Dänzer changed: What|Removed |Added Attachment #125790|text/x-log |text/plain mime type|| -- 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/20160816/53631441/attachment.html>
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 --- Comment #18 from Michel Dänzer --- (In reply to John Brooks from comment #17) > Looks like it may actually have been a kernel regression. > https://bugs.freedesktop.org/show_bug.cgi?id=97260#c12 We can't be sure about that until the problem is fully understood / fixed. So far it still seems more likely that the kernel change triggered an existing issue somewhere else. -- You are receiving this mail because: You are watching the assignee of the bug.
