dri-devel May 2019

dri-devel@lists.freedesktop.org

299 participants
2118 discussions

[PATCH v10 0/2] Mixel MIPI DPHY support for NXPs i.MX8 SOCs
by Guido Günther 08 May '19

08 May '19

This adds initial support for the Mixel IP based mipi dphy as found on i.MX8 processors. It has support for the i.MX8MQ, support for other variants can be added - once the platform specific parts are in - via the provided devdata. The driver is somewhat based on what's found in NXPs BSP. Public documentation on the DPHY's registers is currently thin in the i.MX8 reference manuals (even on the i.MX8QXP form 11/18) so most of the values were taken from existing drivers. Newer NXP drivers have a bit more details so where possible the timings are calculated and validated. This was tested with the an initial version of a NWL MIPI DSI host controller driver https://lists.freedesktop.org/archives/dri-devel/2019-March/209685.html and a forward ported DCSS driver on linux-next 20190506. Robert Chiras (the author of the corresponding driver in NXPs vendor tree) got this driver to work in his tree as well using mxsfb: https://www.spinics.net/lists/arm-kernel/msg711950.html Changes from v9 * As per review comments from Fabio Estevam * Sort includes alphabetically * Remove excessive new lines between functions * Drop error message on devm_ioremap_resource, handled by the core already. * Don't default to it on i.MX8 * As per review comments from Sam Ravnborg * Use clearer variablenames: struct regmap *regs -> regmap void __iomem *regs -> base * Use u32 for all parameters of get_best_ratio() * Don't use non-ascii symbols in debug message * Change MODULE_LICENSE to GPL * As per review comment from Andreas Färber * Change co-authored-by: to co-developed-by: * Collect Signed-off-by from Robert Chiras Changes from v8 * Collect Reviewed-by from Rob Herring * Fix {hs,clk}_prepare vs {hs,clk}_zero debug print out Changes from v7 * As per review comments from Rob Herring * Use fsl, as vendor prefix * Drop changes to vendor-prefixes.txt due to that * Shorten mixel_dphy to dphy in the example * Fix an indentation error noticed by checkpatch that got introduced in v6 * Use lowercase letters in hex addresses in DT bindings example Changes from v6 * Depend on HAS_IOMEM (fixes a build problem on UM spotted by kbuild) Changes from v5 * Fix build problems on mips (spotted by the kbuild test robot) by using u32 consistently and long long for lp_t. Changes from v4 * Build by default on ARCH_MXC && ARM64 Changes form v3 * Check correct variable after devm_ioremap_resource * Add Robert Chiras as Co-authored-by since he's the author of the driver in NXPs BSP. Changes from v2 * As per review comments from Fabio Estevam * KConfig: select REGMAP_MMIO * Drop phy_read * Don't make phy_write inline * Remove duplicate debugging output * Comment style and typo fixes * Add #defines's for PLL lock timing values * Return correct error value when PLL fails to lock * Check error when enabling clock * Use devm_ioremap_resource * As per review comments from Robert Chiras * Deassert PD_DPHY after PLL lock (as per mixel ref manual) * Assert PD_{DPHY,PLL} before power on (as per mixel ref manual)manual * Add exit phy_op to reset CN/CM/CO Changes from v1 * As per review comments from Fabio Estevam * Kconfig: tristate mixel dphy support. * Drop unused 'ret' in mixel_dphy_ref_power_off. * Match values of DPHY_RXL{PRP,DRP} to those of https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_4.14.78_1.0… The previous values were based on 4.9. * Use resource size on devm_ioremap, we have that in dt already. * Use regmap so it's simple to dump the registers. * Use regmap_read_poll_timeout instead of open coded loop. * Add undocumented rxhs_settle register * As per review comments from Sam Ravnborg * Move driver to d/phy/freescale/ * Move SPDX-License-Identifier to top of file. * Drop '/* #define DEBUG 1 */'. * Use GPL-2.0+ since the vendor driver uses that as well. * Drop the mutex, register access is now protected by regmap. * Fix various style / indentation issues. * Check for register read, write and ioremap errors * Improve phy timing calculations * Use LP clock rate where sensible, check for errors * Use ad hoc forumulas for timings involving hs clock * Switch from dphy_ops to devdata. Other i.MX8 variants differ in register layout too * Add Mixel Inc to vendor-prefixes.txt Guido Günther (2): dt-bindings: phy: Add documentation for mixel dphy phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs .../bindings/phy/mixel,mipi-dsi-phy.txt | 29 + drivers/phy/freescale/Kconfig | 10 + drivers/phy/freescale/Makefile | 1 + .../phy/freescale/phy-fsl-imx8-mipi-dphy.c | 499 ++++++++++++++++++ 4 files changed, 539 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c -- 2.20.1

3 6

[PATCH] drm/atomic: Check that the config funcs exist drm_mode_alloc
by Jordan Crouse 08 May '19

08 May '19

An error while initializing the msm driver ends up calling drm_atomic_helper_shutdown() without first initializing the funcs in mode_config. While I'm not 100% sure this isn't a ordering problem in msm adding a check to drm_mode_alloc seems like a nice and safe solution. Signed-off-by: Jordan Crouse <jcrouse(a)codeaurora.org> --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5eb4013..1729428 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -114,6 +114,9 @@ drm_atomic_state_alloc(struct drm_device *dev) { struct drm_mode_config *config = &dev->mode_config; + if (!config->funcs) + return NULL; + if (!config->funcs->atomic_state_alloc) { struct drm_atomic_state *state; -- 2.7.4

2 1

[PATCH 3/3] drm/bridge: it6505 driver add char device feature.
by allen 08 May '19

08 May '19

From: Allen Chen <allen.chen(a)ite.com.tw> This add can let us find it6505 char device in the /dev file and use read/write function to let the driver be hold. Signed-off-by: Allen Chen <allen.chen(a)ite.com.tw> --- drivers/gpu/drm/bridge/ite-it6505.c | 131 ++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c index 13079a8..1529e61 100644 --- a/drivers/gpu/drm/bridge/ite-it6505.c +++ b/drivers/gpu/drm/bridge/ite-it6505.c @@ -70,6 +70,13 @@ /* if use this define will enable SHA debug */ /* #define SHA_DEBUG */ +/* register char device for it6505 */ +#define IT6505_CLASS_NAME "it6505_class" +#define IT6505_DEVICE_NAME "it6505_device" +#define IT6505_MAX_DEV 128 +/* The device major number */ +static int it6505_major_num; + enum sys_status { SYS_UNPLUG = 0, SYS_HPD, @@ -144,6 +151,8 @@ struct it6505 { struct it6505_platform_data pdata; struct mutex lock; struct regmap *regmap; + struct cdev cdev; + struct device class_dev; struct it6505_dp_port *port; /* thread sequence control */ struct semaphore sem_notifier; @@ -2502,6 +2511,80 @@ static int it6505_init_pdata(struct it6505 *it6505) return PTR_ERR_OR_ZERO(pdata->gpiod_reset); } +static int it6505_open(struct inode *inode, struct file *file) +{ + struct it6505 *ctx = container_of(inode->i_cdev, struct it6505, cdev); + + DRM_DEBUG_DRIVER("[%s]: successful", __func__); + if (!ctx) + DRM_DEBUG_DRIVER("[%s]:get it6505 struct fail!", __func__); + file->private_data = ctx; + get_device(&ctx->class_dev); + return 0; +} + +static int it6505_release(struct inode *inode, struct file *file) +{ + struct it6505 *ctx = file->private_data; + + DRM_DEBUG_DRIVER("[%s]: successful", __func__); + put_device(&ctx->class_dev); + return 0; +} + +static ssize_t it6505_read(struct file *file, char *buf, + size_t count, loff_t *ptr) +{ + struct it6505 *ctx = file->private_data; + char kbuff[16]; + size_t len; + + DRM_DEBUG_DRIVER("[%s]start count=%zu", __func__, count); + DRM_DEBUG_DRIVER("it6505_drv_hold:%d", ctx->it6505_drv_hold); + len = snprintf(kbuff, sizeof(kbuff), "%d", ctx->it6505_drv_hold); + len = min3(count, len, sizeof(kbuff)); + return copy_to_user(buf, kbuff, len) ? -EFAULT : len; +} + +static ssize_t it6505_write(struct file *file, const char *buff, + size_t count, loff_t *ptr) +{ + struct it6505 *ctx = file->private_data; + char kbuff[16]; + int num; + + DRM_DEBUG_DRIVER("[%s]start count=%zu", __func__, count); + count = min(count, sizeof(kbuff) - 1); + if (copy_from_user(kbuff, buff, count)) + return -EFAULT; + kbuff[count] = '\0'; + if (kstrtoint(kbuff, 10, &num) < 0) + return -EINVAL; + ctx->it6505_drv_hold = num; + DRM_DEBUG_DRIVER("set it6505_drv_hold:%d", ctx->it6505_drv_hold); + return count; +} + +static struct class it6505_class_file = { + .owner = THIS_MODULE, + .name = IT6505_CLASS_NAME, +}; + +static const struct file_operations it6505_fops = { + .owner = THIS_MODULE, + .read = it6505_read, + .write = it6505_write, + .open = it6505_open, + .release = it6505_release +}; + +static void it6505_release_device(struct device *dev) +{ + struct it6505 *ctx = container_of(dev, struct it6505, class_dev); + + kfree(ctx); +} + static int it6505_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -2575,8 +2658,38 @@ static int it6505_i2c_probe(struct i2c_client *client, ctx->bridge.funcs = &it6505_bridge_funcs; drm_bridge_add(&ctx->bridge); + device_initialize(&ctx->class_dev); + ctx->class_dev.parent = &client->dev; + ctx->class_dev.release = it6505_release_device; + cdev_init(&ctx->cdev, &it6505_fops); + err = dev_set_name(&ctx->class_dev, "%s", IT6505_DEVICE_NAME); + DRM_DEBUG_DRIVER("[%s] dev_set_name:%s", + __func__, err ? "failed" : "success"); + if (err) { + DRM_DEBUG_DRIVER("dev_set_name failed => %d", err); + goto put_class_dev; + } + /* + * Add the class device + * Link to the character device for creating the /dev entry + * in devtmpfs. + */ + ctx->class_dev.devt = MKDEV(it6505_major_num, 0); + ctx->class_dev.class = &it6505_class_file; + + /* We can now add the sysfs class, we know which parameter to show */ + err = cdev_device_add(&ctx->cdev, &ctx->class_dev); + if (err) { + DRM_DEBUG_DRIVER("cdev_device_add failed => %d", + err); + goto put_class_dev; + } DRM_DEBUG_DRIVER("[%s]end", __func__); return 0; + +put_class_dev: + put_device(&ctx->class_dev); + return err; } static int it6505_remove(struct i2c_client *client) @@ -2616,16 +2729,34 @@ struct i2c_driver it6505_i2c_driver = { static int __init it6505_init(void) { + int err; + dev_t dev = 0; + DRM_DEBUG_DRIVER("[%s]start", __func__); + /* Register the device class */ + err = class_register(&it6505_class_file); + err = alloc_chrdev_region(&dev, 0, IT6505_MAX_DEV, + IT6505_DEVICE_NAME); + it6505_major_num = MAJOR(dev); + if (err < 0) { + DRM_DEBUG_DRIVER("alloc_chrdev_region() fail!"); + goto failed_chrdevreg; + } i2c_add_driver(&it6505_i2c_driver); DRM_DEBUG_DRIVER("[%s]end", __func__); return 0; + +failed_chrdevreg: + class_unregister(&it6505_class_file); + return err; } static void __exit it6505_exit(void) { DRM_DEBUG_DRIVER("[%s]start", __func__); i2c_del_driver(&it6505_i2c_driver); + unregister_chrdev(it6505_major_num, IT6505_DEVICE_NAME); + class_unregister(&it6505_class_file); DRM_DEBUG_DRIVER("[%s]end", __func__); } -- 1.9.1

1 0

[drm-tip:drm-tip /8] drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting'
by kbuild test robot 08 May '19

08 May '19

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking branch 'drm-intel/drm-intel-next-queued' into drm-tip config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 47f4a14297839cb4cedd725fb916a5da5eb9b5ba # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> Note: the drm-tip/drm-tip HEAD ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start' i915_request_await_start(struct i915_request *rq, struct i915_request *signal) ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 'i915_request_await_start' was here i915_request_await_start(struct i915_request *rq, struct i915_request *signal) ^~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting' already_busywaiting(struct i915_request *rq) ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_request.c:809:1: note: previous definition of 'already_busywaiting' was here already_busywaiting(struct i915_request *rq) ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_request.c:809:1: warning: 'already_busywaiting' defined but not used [-Wunused-function] drivers/gpu/drm/i915/i915_request.c:794:1: warning: 'i915_request_await_start' defined but not used [-Wunused-function] i915_request_await_start(struct i915_request *rq, struct i915_request *signal) ^~~~~~~~~~~~~~~~~~~~~~~~ vim +/already_busywaiting +842 drivers/gpu/drm/i915/i915_request.c 47f4a1429 drivers/gpu/drm/i915/i915_request.c Joonas Lahtinen 2019-05-07 825 a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09 826 static int e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 @827 i915_request_await_start(struct i915_request *rq, struct i915_request *signal) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 828 { e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 829 if (list_is_first(&signal->ring_link, &signal->ring->request_list)) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 830 return 0; e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 831 e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 832 signal = list_prev_entry(signal, ring_link); e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 833 if (i915_timeline_sync_is_later(rq->timeline, &signal->fence)) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 834 return 0; e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 835 e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 836 return i915_sw_fence_await_dma_fence(&rq->submit, e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 837 &signal->fence, 0, e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 838 I915_FENCE_GFP); e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 839 } e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 840 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 841 static intel_engine_mask_t 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 @842 already_busywaiting(struct i915_request *rq) 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 843 { 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 844 /* 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 845 * Polling a semaphore causes bus traffic, delaying other users of 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 846 * both the GPU and CPU. We want to limit the impact on others, 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 847 * while taking advantage of early submission to reduce GPU 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 848 * latency. Therefore we restrict ourselves to not using more 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 849 * than one semaphore from each source, and not using a semaphore 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 850 * if we have detected the engine is saturated (i.e. would not be 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 851 * submitted early and cause bus traffic reading an already passed 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 852 * semaphore). 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 853 * 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 854 * See the are-we-too-late? check in __i915_request_submit(). 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 855 */ 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 856 return rq->sched.semaphores | rq->hw_context->saturated; 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 857 } 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 858 :::::: The code at line 842 was first introduced by commit :::::: 2564fe708b580c1ef12b2b527ab6e8afe11ad444 drm/i915: Disable semaphore busywaits on saturated systems :::::: TO: Chris Wilson <chris(a)chris-wilson.co.uk> :::::: CC: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

[drm-tip:drm-tip 5/8] drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start'
by kbuild test robot 08 May '19

08 May '19

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 73db4ec12f05160528884c0b2c845b1c6b7c6718 commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking branch 'drm-intel/drm-intel-next-queued' into drm-tip config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout b9a2acf7709f52c77dc752ec99e3873e392d8df6 # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start' i915_request_await_start(struct i915_request *rq, struct i915_request *signal) ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 'i915_request_await_start' was here i915_request_await_start(struct i915_request *rq, struct i915_request *signal) ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_request.c:794:1: warning: 'i915_request_await_start' defined but not used [-Wunused-function] vim +/i915_request_await_start +827 drivers/gpu/drm/i915/i915_request.c ca6e56f65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04 825 a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09 826 static int e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 @827 i915_request_await_start(struct i915_request *rq, struct i915_request *signal) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 828 { e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 829 if (list_is_first(&signal->ring_link, &signal->ring->request_list)) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 830 return 0; e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 831 e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 832 signal = list_prev_entry(signal, ring_link); e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 833 if (i915_timeline_sync_is_later(rq->timeline, &signal->fence)) e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 834 return 0; e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 835 e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 836 return i915_sw_fence_await_dma_fence(&rq->submit, e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 837 &signal->fence, 0, e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 838 I915_FENCE_GFP); e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 839 } e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 840 :::::: The code at line 827 was first introduced by commit :::::: e766fde6511e2be83acbca1d603035e08de23f3b drm/i915: Delay semaphore submission until the start of the signaler :::::: TO: Chris Wilson <chris(a)chris-wilson.co.uk> :::::: CC: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 1

[Bug 110636] [radv] DOOM 2016 particle artifacting
by bugzilla-daemon＠freedesktop.org 08 May '19

08 May '19

https://bugs.freedesktop.org/show_bug.cgi?id=110636 Bug ID: 110636 Summary: [radv] DOOM 2016 particle artifacting Product: Mesa Version: 19.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: lolisamurai(a)tfwno.gf QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 144189 --> https://bugs.freedesktop.org/attachment.cgi?id=144189&action=edit gif showing the artifacting since mesa 19 (using 19.0.2 at the moment), I've been experiencing artifacting / incorrect rendering of particles in DOOM 2016 running on a r9 270x with the amdgpu driver. this happens with both vulkan and opengl renderers. I have attached a gif that shows the artifacts. I also uploaded a renderdoc capture to mega (it's almost 1 gig, so I felt like it would be too much to add as a normal attachment): https://mega.nz/#!EV53mC5Q!vAugOwDn2iKqGaQ-KYNvfXg7oDNlhB3i74DvSnwdYD4 this doesn't happen on mesa 18.3.5 the game is running through proton 3.7-8 on steam. newer proton versions don't help how to reproduce: play any map that contains ambient particles, for example "kagindir sanctum" on arcade or story mode should have them right at the start I don't have a renderdoc of particles working as intended but i will get one when i downgrade to mesa 18 again. you can look up videos of those maps on youtube to see that it's definitely not supposed to look like that. it feels like the intensity and speed of the particles is way higher than it should my system info at the time of capture is also attached -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
by bugzilla-daemon＠freedesktop.org 07 May '19

07 May '19

https://bugs.freedesktop.org/show_bug.cgi?id=107978 Bug ID: 107978 Summary: [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: shtetldik(a)gmail.com After upgrading to Linux 4.19-rc3 (from 4.18.x), I can't switch to tty anymore, the monitor connected over DisplayPort goes into sleep mode. I see this in dmesg when it happens: [37342.777399] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:922 [37342.777477] WARNING: CPU: 4 PID: 14403 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777478] Modules linked in: uas usb_storage rfcomm ebtable_filter ebtables devlink ip6table_filter ip6_tables iptable_filter cmac bnep arc4 nls_ascii nls_cp437 vfat amdkfd fat snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd btusb btrtl amdgpu btbcm snd_hda_codec_hdmi btintel iwlmvm snd_usb_audio snd_hda_intel bluetooth kvm_amd snd_hda_codec snd_usbmidi_lib wmi_bmof mxm_wmi mac80211 snd_hda_core kvm uvcvideo videobuf2_vmalloc snd_hwdep videobuf2_memops snd_rawmidi jitterentropy_rng videobuf2_v4l2 videobuf2_common snd_seq_device chash iwlwifi irqbypass gpu_sched videodev snd_pcm crct10dif_pclmul ttm crc32_pclmul media drbg snd_timer evdev drm_kms_helper cfg80211 ansi_cprng ghash_clmulni_intel efi_pstore pcspkr drm snd k10temp ecdh_generic soundcore efivars rfkill crc16 sp5100_tco sg ccp [37342.777514] rng_core wmi pcc_cpufreq button acpi_cpufreq nct6775 hwmon_vid parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 xfs btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic hid_generic usbhid hid sd_mod crc32c_intel ahci xhci_pci libahci aesni_intel xhci_hcd aes_x86_64 crypto_simd libata igb cryptd glue_helper nvme usbcore scsi_mod i2c_piix4 i2c_algo_bit nvme_core dca usb_common gpio_amdpt gpio_generic [37342.777542] CPU: 4 PID: 14403 Comm: kworker/4:1 Tainted: G W 4.19.0-rc3-amd64 #1 Debian 4.19~rc3-1~exp1 [37342.777542] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Taichi, BIOS L4.64 04/03/2018 [37342.777558] Workqueue: events drm_mode_rmfb_work_fn [drm] [37342.777615] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777617] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 20 9d b5 c1 e8 64 e6 f0 fe 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [37342.777618] RSP: 0018:ffffa2ae81b9ba20 EFLAGS: 00010297 [37342.777620] RAX: 0000000000000000 RBX: 000000000000000a RCX: 0000000000000000 [37342.777621] RDX: 0000000000000000 RSI: ffff93d74eb166a8 RDI: ffff93d74eb166a8 [37342.777622] RBP: ffff93d746439180 R08: 0000000000000000 R09: 0000000000010200 [37342.777623] R10: 0720072007200720 R11: 0720073207320739 R12: 0000000000000bb9 [37342.777624] R13: 00000000000051e2 R14: 0000000000010000 R15: 0000000000000000 [37342.777625] FS: 0000000000000000(0000) GS:ffff93d74eb00000(0000) knlGS:0000000000000000 [37342.777626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37342.777627] CR2: 0000558f62bfa9d0 CR3: 00000003f2c38000 CR4: 00000000003406e0 [37342.777628] Call Trace: [37342.777695] dce110_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [37342.777754] core_link_disable_stream+0x54/0x220 [amdgpu] [37342.777813] dce110_reset_hw_ctx_wrap+0xc1/0x1e0 [amdgpu] [37342.777872] dce110_apply_ctx_to_hw+0x45/0x650 [amdgpu] [37342.777928] ? dc_remove_plane_from_context+0x1fc/0x240 [amdgpu] [37342.777985] dc_commit_state+0x2c6/0x520 [amdgpu] [37342.778047] amdgpu_dm_atomic_commit_tail+0x37a/0xd80 [amdgpu] [37342.778052] ? __wake_up_common_lock+0x89/0xc0 [37342.778054] ? _cond_resched+0x15/0x30 [37342.778056] ? wait_for_completion_timeout+0x3b/0x1a0 [37342.778117] ? amdgpu_dm_atomic_commit_tail+0xd80/0xd80 [amdgpu] [37342.778126] commit_tail+0x3d/0x70 [drm_kms_helper] [37342.778133] drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper] [37342.778148] drm_framebuffer_remove+0x361/0x410 [drm] [37342.778164] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] [37342.778167] process_one_work+0x1a7/0x360 [37342.778169] worker_thread+0x30/0x390 [37342.778171] ? pwq_unbound_release_workfn+0xd0/0xd0 [37342.778173] kthread+0x112/0x130 [37342.778175] ? kthread_bind+0x30/0x30 [37342.778177] ret_from_fork+0x22/0x40 [37342.778179] ---[ end trace 3d987dd66a59ffb4 ]--- OS: Debian testing, kernel 4.19~rc3-1~exp1 GPU: Sapphire Pulse Vega 56. amdgpu firmware: 20180825+dfsg-1 -- You are receiving this mail because: You are the assignee for the bug.

1 63

[Bug 109619] Add new alias for R600_TEX_ANISO for radeonsi
by bugzilla-daemon＠freedesktop.org 07 May '19

07 May '19

https://bugs.freedesktop.org/show_bug.cgi?id=109619 Bug ID: 109619 Summary: Add new alias for R600_TEX_ANISO for radeonsi Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: shtetldik(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Now that radeonsi and r600 have separate code, R600_TEX_ANISO variable for forcing anisotropic filtering looks out of place for radeonsi. While it might be good to keep it for backwards compatibility and not breaking existing usage, it would be nice to have some more appropriate alias as well. May be RADEONSI_TEX_ANISO? Or may be make a new alias for both, like AMD_TEX_ANISO to simplify things. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master
by John Stultz 07 May '19

07 May '19

Somewhat recent changes in the AOSP build system has been made which fairly severely restricts the build environment. This has made it difficult to test mesa/master w/ AOSP/master. I'm working with others to try to remedy this, but as a first step I used some hacks to temporarily remove the build environment restrictions, and unsuprizingly found mesa/master has a few build issues when trying to build w/ freedreno. So this patch set provides only some very basic build fixes that are needed to get mesa/master building w/ AOSP/master (minus the build restrictions on external tools). Feedback would be greatly appreciated! thanks -john Cc: Rob Clark <robdclark(a)chromium.org> Cc: Emil Velikov <emil.l.velikov(a)gmail.com> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Alistair Strachan <astrachan(a)google.com> Cc: Greg Hartman <ghartman(a)google.com> Cc: Tapani Pälli <tapani.palli(a)intel.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Alistair Strachan (1): mesa: android: Remove unnecessary dependency tracking rules Amit Pundir (1): mesa: android: freedreno: build libfreedreno_{drm,ir3} static libs John Stultz (1): mesa: android: freedreno: Fix build failure due to path change Android.mk | 1 + src/compiler/Android.glsl.gen.mk | 2 - src/compiler/Android.nir.gen.mk | 2 - src/freedreno/Android.drm.mk | 41 ++++++++++++++++ src/freedreno/Android.ir3.mk | 51 ++++++++++++++++++++ src/freedreno/Android.mk | 30 ++++++++++++ src/freedreno/Makefile.sources | 2 + src/gallium/Android.common.mk | 5 +- src/gallium/drivers/freedreno/Android.gen.mk | 2 +- src/gallium/drivers/freedreno/Android.mk | 2 +- src/gallium/targets/dri/Android.mk | 4 ++ 11 files changed, 135 insertions(+), 7 deletions(-) create mode 100644 src/freedreno/Android.drm.mk create mode 100644 src/freedreno/Android.ir3.mk create mode 100644 src/freedreno/Android.mk -- 2.17.1

6 13

[PATCH v2 1/3] dt-bindings: display: Document FriendlyELEC HD702E LCD panel
by Jagan Teki 07 May '19

07 May '19

HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 resolution. It has built in Goodix, GT9271 captive touchscreen with backlight adjustable via PWM. Add dt-bindings documentation for it. Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- Changes for v2: - separate binding patch from driver - Add simple-panel compatible as fallback - Add text info about simple-panel bindings .../display/panel/friendlyarm,hd702e.txt | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt diff --git a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt new file mode 100644 index 000000000000..6c9156fc3478 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt @@ -0,0 +1,32 @@ +FriendlyELEC HD702E 800x1280 LCD panel + +HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 +resolution. It has built in Goodix, GT9271 captive touchscreen +with backlight adjustable via PWM. + +Required properties: +- compatible: should be "friendlyarm,hd702e" +- power-supply: regulator to provide the supply voltage + +Optional properties: +- backlight: phandle of the backlight device attached to the panel + +Optional nodes: +- Video port for LCD panel input. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. + +Example: + + panel { + compatible ="friendlyarm,hd702e", "simple-panel"; + backlight = <&backlight>; + power-supply = <&vcc3v3_sys>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&edp_out_panel>; + }; + }; + }; -- 2.18.0.321.gffc6fa0e3

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2019