[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs
https://bugs.freedesktop.org/show_bug.cgi?id=96672 Bug ID: 96672 Summary: [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: shawn.starr at rogers.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 124710 --> https://bugs.freedesktop.org/attachment.cgi?id=124710=edit Correct rendering I've discovered a regression in ARK. It appears our usage of LLVM 3.9 broke ARK while LLVM 3.8 is fine. Bisecting mesa from November 19th, I was unable to see any issues using LLVM 3.8, this includes Git mesa master. Attached is two screenshots using LLVM 3.8/3.9 showing the same scene. The text is missing in the top and in other places in game where certain text is used. -- 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/20160625/1b6fbc7c/attachment-0001.html>
[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs
https://bugs.freedesktop.org/show_bug.cgi?id=96672 --- Comment #1 from Shawn Starr --- Created attachment 124711 --> https://bugs.freedesktop.org/attachment.cgi?id=124711=edit Incorrect rendering of text glyph (completely missing) -- 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/20160625/21e7daea/attachment.html>
[PATCH 1/2] drm/ttm: fix stupid parameter inversion in the pipeline code
On Fri, Jun 24, 2016 at 3:51 PM, Christian König wrote: > From: Christian König > > We want to keep the newest fence, not the oldest one. > > Signed-off-by: Christian König Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > b/drivers/gpu/drm/ttm/ttm_bo_util.c > index 0c389a5..4da0e78 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -753,7 +753,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo, > */ > > spin_lock(>move_lock); > - if (!from->move || fence_is_later(from->move, fence)) { > + if (!from->move || fence_is_later(fence, from->move)) { > fence_put(from->move); > from->move = fence_get(fence); > } > -- > 2.5.0 > > ___ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[drm-intel:for-linux-next 5/22] drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 883445d43e45ddc5ef19274a169a1aa603428ab6 commit: 1dac891c1c95a8528f3558b481fbb9a45d653619 [5/22] drm/i915: Register debugfs interface last config: x86_64-randconfig-s2-06251012 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: git checkout 1dac891c1c95a8528f3558b481fbb9a45d653619 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/intel_dp_mst.c:27:0: drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_register': >> drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted static inline int i915_debugfs_register(struct drm_i915_private *) {return 0;} ^~~~ drivers/gpu/drm/i915/i915_drv.h: In function 'i915_debugfs_unregister': drivers/gpu/drm/i915/i915_drv.h:3613:51: error: parameter name omitted static inline void i915_debugfs_unregister(struct drm_i915_private *) {} ^~~~ vim +3612 drivers/gpu/drm/i915/i915_drv.h 3606 #ifdef CONFIG_DEBUG_FS 3607 int i915_debugfs_register(struct drm_i915_private *dev_priv); 3608 void i915_debugfs_unregister(struct drm_i915_private *dev_priv); 3609 int i915_debugfs_connector_add(struct drm_connector *connector); 3610 void intel_display_crc_init(struct drm_device *dev); 3611 #else > 3612 static inline int i915_debugfs_register(struct drm_i915_private *) > {return 0;} 3613 static inline void i915_debugfs_unregister(struct drm_i915_private *) {} 3614 static inline int i915_debugfs_connector_add(struct drm_connector *connector) 3615 { return 0; } --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 29187 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160625/d58f3edd/attachment-0001.obj>
[radeon-alex:polaris-test 19/19] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1798:4: warning: this decimal constant is unsigned only in ISO C90
tree: git://people.freedesktop.org/~agd5f/linux.git polaris-test head: 0812a945fbb814e7946fbe6ddcc81d054c8b6c91 commit: 0812a945fbb814e7946fbe6ddcc81d054c8b6c91 [19/19] drm/amd/powerplay: Update CKS on/ CKS off voltage offset calculation config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: git checkout 0812a945fbb814e7946fbe6ddcc81d054c8b6c91 # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c: In function 'polaris10_populate_clock_stretcher_data_table': >> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1798:4: >> warning: this decimal constant is unsigned only in ISO C90 volt_without_cks = (uint32_t)((2753594000 + (sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \ ^~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1803:4: warning: this decimal constant is unsigned only in ISO C90 volt_without_cks = (uint32_t)((2416794800 + (sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \ ^~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c:1805:4: warning: this decimal constant is unsigned only in ISO C90 volt_with_cks = (uint32_t)((2999656000 + sclk_table->entries[i].clk * 392803/100 - (ro - 44) * 100) / \ ^ vim +1798 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/polaris10_hwmgr.c 1782 min = 1000; 1783 max = 2300; 1784 } else { 1785 min = 1100; 1786 max = 2100; 1787 } 1788 1789 ro = efuse * (max -min)/255 + min; 1790 1791 /* Populate Sclk_CKS_masterEn0_7 and Sclk_voltageOffset 1792 * there is a little difference in calculating 1793 * volt_with_cks with windows */ 1794 for (i = 0; i < sclk_table->count; i++) { 1795 data->smc_state_table.Sclk_CKS_masterEn0_7 |= 1796 sclk_table->entries[i].cks_enable << i; 1797 if (hwmgr->chip_id == CHIP_POLARIS10) { > 1798 volt_without_cks = (uint32_t)((2753594000 + > (sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \ 1799 (2424180 - (sclk_table->entries[i].clk/100) * 1132925/1000)); 1800 volt_with_cks = (uint32_t)((279720200 + sclk_table->entries[i].clk * 3232 - (ro - 65) * 1) / \ 1801 (252248000 - sclk_table->entries[i].clk/100 * 115764)); 1802 } else { 1803 volt_without_cks = (uint32_t)((2416794800 + (sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \ 1804 (2625416 - (sclk_table->entries[i].clk/100) * 12586807/1)); 1805 volt_with_cks = (uint32_t)((2999656000 + sclk_table->entries[i].clk * 392803/100 - (ro - 44) * 100) / \ 1806 (3422454 - sclk_table->entries[i].clk/100 * 18886376/1)); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 55035 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160625/a4c91bb2/attachment-0001.obj>
[PATCH 04/25] drm: Restore double clflush on the last partial cacheline
This effectively reverts commit afcd950cafea6e27b739fe7772cbbeed37d05b8b Author: Chris Wilson Date: Wed Jun 10 15:58:01 2015 +0100 drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range() as we have observed issues with serialisation of the clflush operations on Baytrail+ Atoms with partial updates. Applying the double flush on the last cacheline forces that clflush to be ordered with respect to the previous clflush, and the mfence then protects against prefetches crossing the clflush boundary. The same issue can be demonstrated in userspace with igt/gem_exec_flush. Fixes: afcd950cafea6 (drm: Avoid the double clflush on the last cache...) Testcase: igt/gem_concurrent_blit Testcase: igt/gem_partial_pread_pwrite Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845 Signed-off-by: Chris Wilson Cc: dri-devel at lists.freedesktop.org Cc: Akash Goel Cc: Imre Deak Cc: Daniel Vetter Cc: Jason Ekstrand Cc: stable at vger.kernel.org Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/drm_cache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index 059f7c39c582..a7916e5f8864 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -136,6 +136,7 @@ drm_clflush_virt_range(void *addr, unsigned long length) mb(); for (; addr < end; addr += size) clflushopt(addr); + clflushopt(end - 1); /* force serialisation */ mb(); return; } -- 2.8.1
[PATCH 1/3] drm/vgem: Fix mmaping
On Thu, Jun 23, 2016 at 03:35:32PM +0100, Chris Wilson wrote: > The vGEM mmap code has bitrotted slightly and now immediately BUGs. > Since vGEM was last updated, there are new core GEM facilities to > provide more common functions, so let's use those here. > > v2: drm_gem_free_mmap_offset() is performed from > drm_gem_object_release() so we can remove the redundant call. > > Testcase: igt/vgem_basic/mmap > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603 > Signed-off-by: Chris Wilson > Cc: Sean Paul > Cc: Zach Reizner > Cc: Matthew Auld > Tested-by: Humberto Israel Perez Rodriguez intel.com> > Reviewed-by: Matthew Auld Hi Thierry, Daniel recommended to bug you for stewardship of drm-misc in his absence. Could you please consider this patch? Our CI is now tripping over this issue. Sean or Zach could you please ack? And have a look at the following pair of dma-buf fence patches? I have tests ready for our CI that use the vgem dma-buf to demonstrate the lack of synchronisation in i915.ko (and so exercise the fixes without requiring a second piece of hardware). -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCHv16 04/13] cec: add HDMI CEC framework
On 06/16/2016 06:00 PM, Mauro Carvalho Chehab wrote: > Em Fri, 29 Apr 2016 15:52:19 +0200 > Hans Verkuil escreveu: > >> From: Hans Verkuil >> >> The added HDMI CEC framework provides a generic kernel interface for >> HDMI CEC devices. >> >> Besides the cec module itself it also adds a cec-edid module that >> contains helper functions to find and manipulate the CEC physical >> address inside an EDID. Even if the CEC support itself is disabled, >> drivers will still need these functions. >> >> Note that the CEC framework is added to staging/media and that the >> cec.h and cec-funcs.h headers are not exported yet. While the kABI >> is mature, I would prefer to allow the uABI some more time before >> it is mainlined in case it needs more tweaks. > > As pointed via IRC, it sounds like checkpatch were never used > on this patch series. Just this one got more than 100 errors/warnings: > > total: 6 errors, 107 warnings, 5895 lines checked > > NOTE: For some of the reported defects, checkpatch may be able to > mechanically convert to the typical style using --fix or --fix-inplace. > > Please fix, except if you have a good reason why not follow the > CodingStyle. When I saw this reply the first time I thought you gave up reviewing at this point and I missed all the review comments below. Apologies for that! >> +static unsigned cec_get_edid_spa_location(const u8 *edid, unsigned size) >> +{ >> +u8 d; >> + >> +if (size < 256) >> +return 0; >> + >> +if (edid[0x7e] != 1 || edid[0x80] != 0x02 || edid[0x81] != 0x03) >> +return 0; > > Hmm... looking at E-EDID spec: > http://read.pudn.com/downloads110/ebook/456020/E-EDID%20Standard.pdf > > you're expecting that EDID will have just *one* extension? If so, please > state so, adding a FIXME to warn about future needs to change the code > to support bigger EDID data. Also, in such case, the EDID size should > always be 256. I've improved the code to accept more than one extension block. Note that any device that puts the CEA-861 block in a different position is unlikely to work. Most HDMI receivers only support one extension block. > I would also check the checksum, to be sure that the vendor specific > data block is not pointing to some invalid location. This should not happen. I think it is safe to assume that the EDID is correct when this function is called. Invalid EDIDs should be rejected when they are read. > >> + >> +/* search Vendor Specific Data Block (tag 3) */ >> +d = edid[0x82] & 0x7f; >> +if (d > 4) { >> +int i = 0x84; >> +int end = 0x80 + d; >> + >> +do { >> +u8 tag = edid[i] >> 5; >> +u8 len = edid[i] & 0x1f; >> + >> +if (tag == 3 && len >= 5) >> +return i + 4; >> +i += len + 1; >> +} while (i < end); >> +} > > It looked weird that check for size at the beginning, since the size > is not being used in the routine itself. Ok, after looking at the > code 3 or 4 times, I understood that you're implicitly using the > size at the "end" variable, as you're doing a loop between > 'd', with ranges from 0 to 0x7f > 'end', with ranges from 0x85 to 0xff. > 'i', ranging from 0x84 to 0xfe. > return value, ranging from 0x88 to 0x102 (i + 4) > > As the code seems to rely on having just one extension, allowing to go > past 0xff seems a mistake. > > I guess the loop should be checking if it won't return a value > past of the EDID array. I've made the code more robust to safeguard against broken EDIDs (intentionally or not). > >> +return 0; >> +} >> + >> +u16 cec_get_edid_phys_addr(const u8 *edid, unsigned size, unsigned *offset) >> +{ >> +unsigned loc = cec_get_edid_spa_location(edid, size); >> + >> +if (offset) >> +*offset = loc; >> +if (loc == 0) >> +return CEC_PHYS_ADDR_INVALID; >> +return (edid[loc] << 8) | edid[loc + 1]; > > Yeah, if I'm not mistaken, you may be reading past the EDID > array here, if loc > 0xfe, and size = 256. With the more robust location code this is now guaranteed to be safe. > >> +} >> +EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr); >> + >> +void cec_set_edid_phys_addr(u8 *edid, unsigned size, u16 phys_addr) >> +{ >> +unsigned loc = cec_get_edid_spa_location(edid, size); >> +u8 sum = 0; >> +unsigned i; >> + >> +if (loc == 0) >> +return; >> +edid[loc] = phys_addr >> 8; >> +edid[loc + 1] = phys_addr & 0xff; >> +loc &= ~0x7f; >> + >> +/* update the checksum */ >> +for (i = loc; i < loc + 127; i++) >> +sum += edid[i]; >> +edid[i] = 256 - sum; > > Here, you can also go past the EDID array, as you're not checking the > size inside the for loop. With the more robust location code this is now correct (if loc != 0, then the size is guaranteed to be a multiple of 128). > >> +} >>
[Bug 96588] [regression] [amdgpu] Errors scheduling IBs
https://bugs.freedesktop.org/show_bug.cgi?id=96588 --- Comment #15 from Mike Lothian --- The patch already seems to have landed in drm-next-4.8-wip and it does indeed seem to fix it -- 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/20160625/14a26766/attachment.html>
[Bug 96622] [radeonsi,apitrace] "Dreamfall Chapters: The longest Journey" shows visual corruption
https://bugs.freedesktop.org/show_bug.cgi?id=96622 --- Comment #5 from Nicolai Hähnle --- Great to hear that and thank you for following up on here :) -- 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/20160625/664af248/attachment.html>
[Bug 95528] BioShock Infinite graphical glitches on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=95528 --- Comment #14 from Daniel Scharrer --- Created attachment 124721 --> https://bugs.freedesktop.org/attachment.cgi?id=124721=edit Trimmed R600_DEBUG=vs,ps output & shader GL calls with LLVM r273782 I could not record an apitrace (game hangs before getting to the main menu, possibly performance related), but I was able to dump the shaders and narrow down (some of) the affected ones. The game uses two passes to render the flags and banners: The first pass (possibly a z prepass?) uses pipeline=20 in the attached logs (vertex shader=73, program=74; fragment shader=89, program=90). The second pass is depth-tested against the results of the first, but uses different shaders - pipeline=105 (vertex shader=383 program=384; fragment shader=381, program=382). With LLVM r266378 reverted, the results of the two passes line up, with current LLVM they do not causing the z-fighting visible in the video linked in the bug description. Even when disabling the depth test in the second pass, there are still visible parts of "white" background so this is a) most likely an issue with one of the vertex shaders and b) not just a depth precision issue. You can also see this by looking closely at the flags in the video - the while (holes punched by the z-prepass) and textured parts sway differently. Since the game compiles an enormous amount of shaders on startup, the full R600_DEBUG=cs,vs,tcs,tes,gs,ps output is quite large - I have attached a trimmed output that only contains the two vertex/fragment shader pairs used for the banners. The full logs are available at: http://constexpr.org/tmp/bioshockinfinite-bad.log (20 MiB) http://constexpr.org/tmp/bioshockinfinite-good.log (21 MiB) -- 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/20160625/3603036d/attachment.html>
[Bug 95528] BioShock Infinite graphical glitches on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=95528 --- Comment #15 from Daniel Scharrer --- Created attachment 124722 --> https://bugs.freedesktop.org/attachment.cgi?id=124722=edit Trimmed R600_DEBUG=vs,ps output & shader GL calls with LLVM r273782, but with r266378 reverted -- 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/20160625/a2b22450/attachment.html>
[PATCH 2/4] input: touchscreen: crtouch_ts: Add driver
On 2016-06-24 12:44, Anthony Felice wrote: > Add driver for the Vybrid Tower CRTouch-based touchscreen. This is > required for the touchscreen on the TWR-LCD-RGB to work on the Vybrid > Tower platform. > > There is a known issue with this driver: rarely, SW1 on the TWR-LCD-RGB > module needs to be pressed in order for the touchscreen to begin > functioning. > > Signed-off-by: Anthony Felice > --- > .../bindings/input/touchscreen/crtouch_ts.txt | 14 ++ > drivers/input/touchscreen/Kconfig | 10 + > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/crtouch_ts.c | 279 > + > 4 files changed, 304 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt > create mode 100644 drivers/input/touchscreen/crtouch_ts.c > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt > b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt > new file mode 100644 > index 000..cfb966c > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/touchscreen/crtouch_ts.txt > @@ -0,0 +1,14 @@ > +* Freescale CRTOUCH based touchscreen > + > +Required Properties: > +- compatible must be fsl,crtouch_ts Compatible strings usually use a dash instead of underline. > +- reg: I2C address of the touchscreen > +- irq-gpio: GPIO to use as event IRQ > + > +Example: > + > + touch: crtouch at 49 { > + compatible = "fsl,crtouch_ts"; > + reg = <0x49>; > + irq-gpio = < 21 GPIO_ACTIVE_HIGH>; > + }; > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index 8ecdc38..799e342 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -1155,4 +1155,14 @@ config TOUCHSCREEN_ROHM_BU21023 > To compile this driver as a module, choose M here: the > module will be called bu21023_ts. > > +config TOUCHSCREEN_CRTOUCH > + tristate "Freescale CRTOUCH based touchscreen" > + depends on I2C You probably also need to add OF here. > + help > + Say Y here if you have a CRTOUCH based touchscreen > + controller. > + > + To compile this driver as a module, choose M here: the > + module will be called crtouch_ts. > + > endif > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index f42975e..8cb0a7a 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -95,3 +95,4 @@ obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o > obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o > obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o > obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023) += rohm_bu21023.o > +obj-$(CONFIG_TOUCHSCREEN_CRTOUCH)+= crtouch_ts.o > diff --git a/drivers/input/touchscreen/crtouch_ts.c > b/drivers/input/touchscreen/crtouch_ts.c > new file mode 100644 > index 000..bb87a8e > --- /dev/null > +++ b/drivers/input/touchscreen/crtouch_ts.c > @@ -0,0 +1,279 @@ > +/* > + * Driver for Freescale Semiconductor CRTOUCH - A Resistive and Capacitive > + * touch device with i2c interface > + * > + * Copyright 2012 Freescale Semiconductor, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Resistive touch sense status registers */ > +#define RES_STA_ERROR0x00 > +#define RES_STA_STATUS1 0x01 > +#define RES_STA_STATUS2 0x02 Nit: there is a tab between define and RES_STA_STATUS2, all other lines have spaces. -- Stefan
[PATCH 1/4] ARM: dts: vf610-twr: Enable display controller
On 2016-06-24 12:44, Anthony Felice wrote: > This adds nodes to enable tcon0 and dcu0 for the Vybrid Tower. These > are used to drive the Vybrid Tower TWR-LCD-RGB display. Also, a node > for the nec nl4827hc19-05b panel on the TWR-LCD-RGB display has been > added. So my pixel clock polarity changes which will be part of 4.7 work for Tower? I could never actually test that since I don't have the display here... https://patchwork.kernel.org/patch/8874971/ This patch looks good to me: Acked-by: Stefan Agner -- Stefan > > Signed-off-by: Anthony Felice > --- > arch/arm/boot/dts/vf610-twr.dts | 48 > + > 1 file changed, 48 insertions(+) > > diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts > index cdc1007..ad1aff9 100644 > --- a/arch/arm/boot/dts/vf610-twr.dts > +++ b/arch/arm/boot/dts/vf610-twr.dts > @@ -66,6 +66,10 @@ > clock-frequency = <5000>; > }; > > + panel: panel { > + compatible = "nec,nl4827hc19-05b"; > + }; > + > regulators { > compatible = "simple-bus"; > #address-cells = <1>; > @@ -134,6 +138,13 @@ >< VF610_CLK_ENET_EXT>; > }; > > + { > + fsl,panel = <>; > + pinctrl-names = "default"; > + pinctrl-0 = <_dcu0>; > + status = "okay"; > +}; > + > { > bus-num = <0>; > pinctrl-names = "default"; > @@ -210,6 +221,39 @@ > > { > vf610-twr { > + pinctrl_dcu0: dcu0grp { > + fsl,pins = < > + VF610_PAD_PTE0__DCU0_HSYNC 0x42 > + VF610_PAD_PTE1__DCU0_VSYNC 0x42 > + VF610_PAD_PTE2__DCU0_PCLK 0x42 > + VF610_PAD_PTE4__DCU0_DE 0x42 > + VF610_PAD_PTE5__DCU0_R0 0x42 > + VF610_PAD_PTE6__DCU0_R1 0x42 > + VF610_PAD_PTE7__DCU0_R2 0x42 > + VF610_PAD_PTE8__DCU0_R3 0x42 > + VF610_PAD_PTE9__DCU0_R4 0x42 > + VF610_PAD_PTE10__DCU0_R50x42 > + VF610_PAD_PTE11__DCU0_R60x42 > + VF610_PAD_PTE12__DCU0_R70x42 > + VF610_PAD_PTE13__DCU0_G00x42 > + VF610_PAD_PTE14__DCU0_G10x42 > + VF610_PAD_PTE15__DCU0_G20x42 > + VF610_PAD_PTE16__DCU0_G30x42 > + VF610_PAD_PTE17__DCU0_G40x42 > + VF610_PAD_PTE18__DCU0_G50x42 > + VF610_PAD_PTE19__DCU0_G60x42 > + VF610_PAD_PTE20__DCU0_G70x42 > + VF610_PAD_PTE21__DCU0_B00x42 > + VF610_PAD_PTE22__DCU0_B10x42 > + VF610_PAD_PTE23__DCU0_B20x42 > + VF610_PAD_PTE24__DCU0_B30x42 > + VF610_PAD_PTE25__DCU0_B40x42 > + VF610_PAD_PTE26__DCU0_B50x42 > + VF610_PAD_PTE27__DCU0_B60x42 > + VF610_PAD_PTE28__DCU0_B70x42 > + >; > + }; > + > pinctrl_adc0_ad5: adc0ad5grp { > fsl,pins = < > VF610_PAD_PTC30__ADC0_SE5 0xa1 > @@ -370,6 +414,10 @@ > status = "okay"; > }; > > + { > + status = "okay"; > +}; > + > { > pinctrl-names = "default"; > pinctrl-0 = <_uart1>;
[GIT PULL] drm/fsl-dcu: reworked suspend/resume for v4.8
Hi Dave, This is the main dcu-fsl pull request for 4.8. It depends on a fix which is part of 4.7-rc3, hence this is based ontop of v4.7-rc3 (but merges fine with current drm-next). The patchset contains a new helper in drm_fb_cma_helper.c for suspend/ resume when using cma backed framebuffers. The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5: Linux 4.7-rc3 (2016-06-12 07:20:35 -0700) are available in the git repository at: http://git.agner.ch/git/linux-drm-fsl-dcu.git for-next for you to fetch changes up to f5bce4309db6597003e683d28d12b1b4bc9408b0: drm/fsl-dcu: disable vblank events on CRTC disable (2016-06-18 18:34:31 -0700) Stefan Agner (6): drm/fb_cma_helper: add suspend helper drm/fsl-dcu: store layer registers in soc_data drm/fsl-dcu: move layer initialization to plane file drm/fsl-dcu: use clk helpers drm/fsl-dcu: implement suspend/resume using atomic helpers drm/fsl-dcu: disable vblank events on CRTC disable drivers/gpu/drm/drm_fb_cma_helper.c | 15 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 21 - drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 47 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 2 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 16 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 1 + include/drm/drm_fb_cma_helper.h | 1 + 7 files changed, 76 insertions(+), 27 deletions(-)
[PATCH 1/2] drm:fsl-dcu: rework codes to support of_graph dt binding for panel
Use "drm/fsl-dcu:" in the subject, that is what we commonly used. On 2016-06-24 02:00, Meng Yi wrote: > This patch rework the output code to add of_graph dt binding support > for panel device and also keeps the backward compatibility > > Signed-off-by: Meng Yi > --- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 3 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 76 > > 3 files changed, 57 insertions(+), 24 deletions(-) I tested the patch with the old and new Syntax on a Colibri module, seems to work fine. From a 210 lines patchset to a patchset which adds barley 47 lines net... Nice work! Please update the binding documentation with the new syntax, and mention that fsl,panel property is deprecated. Also add a patch which updates the existing device trees using port/endpoints. > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > index c564ec6..b48ffa7 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > @@ -43,7 +43,7 @@ int fsl_dcu_drm_modeset_init(struct > fsl_dcu_drm_device *fsl_dev) > if (ret) > goto fail_encoder; > > - ret = fsl_dcu_drm_connector_create(fsl_dev, _dev->encoder); > + ret = fsl_dcu_create_outputs(fsl_dev); > if (ret) > goto fail_connector; > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h > index 7093109..5a7b88e 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h > @@ -25,9 +25,8 @@ to_fsl_dcu_connector(struct drm_connector *con) >: NULL; > } > > -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev, > - struct drm_encoder *encoder); > int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev, > struct drm_crtc *crtc); > +int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev); > > #endif /* __FSL_DCU_DRM_CONNECTOR_H__ */ > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > index 98c998d..57a030b 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include Add that some lines above, where the other linux/ includes are. > > #include "fsl_dcu_drm_drv.h" > #include "fsl_tcon.h" > @@ -141,15 +142,15 @@ static const struct drm_connector_helper_funcs > connector_helper_funcs = { > .mode_valid = fsl_dcu_drm_connector_mode_valid, > }; > > -int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev, > - struct drm_encoder *encoder) > +static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev, There is a superfluous space after fsl_dcu_drm_device. > + struct drm_panel *panel) > { > + struct drm_encoder *encoder = _dev->encoder; > struct drm_connector *connector = _dev->connector.base; > struct drm_mode_config *mode_config = _dev->drm->mode_config; > - struct device_node *panel_node; > int ret; > > - fsl_dev->connector.encoder = encoder; > + fsl_dev->connector.encoder = _dev->encoder; > > ret = drm_connector_init(fsl_dev->drm, connector, >_dcu_drm_connector_funcs, > @@ -170,21 +171,7 @@ int fsl_dcu_drm_connector_create(struct > fsl_dcu_drm_device *fsl_dev, > mode_config->dpms_property, > DRM_MODE_DPMS_OFF); > > - panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0); > - if (!panel_node) { > - dev_err(fsl_dev->dev, "fsl,panel property not found\n"); > - ret = -ENODEV; > - goto err_sysfs; > - } > - > - fsl_dev->connector.panel = of_drm_find_panel(panel_node); > - if (!fsl_dev->connector.panel) { > - ret = -EPROBE_DEFER; > - goto err_panel; > - } > - of_node_put(panel_node); > - > - ret = drm_panel_attach(fsl_dev->connector.panel, connector); > + ret = drm_panel_attach(panel, connector); > if (ret) { > dev_err(fsl_dev->dev, "failed to attach panel\n"); > goto err_sysfs; > @@ -192,11 +179,58 @@ int fsl_dcu_drm_connector_create(struct > fsl_dcu_drm_device *fsl_dev, > > return 0; > > -err_panel: > - of_node_put(panel_node); > err_sysfs: > drm_connector_unregister(connector); > err_cleanup: > drm_connector_cleanup(connector); > return ret; > } > + > +static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev, > + const struct of_endpoint *ep) > +{ > + struct device_node *np; > + int ret; > +
[PATCH 2/2] drm:fsl-dcu: add support for drm bridge
On 2016-06-24 02:00, Meng Yi wrote: > The current output code only supports connection to drm panels. > Add codes to support drm bridge, to supports connection to I sense to many s here. Code in the C program code sense is typically an uncountable noun, hence drop the s. And "to support connections" > external connectors. > > Signed-off-by: Meng Yi > --- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > index 57a030b..f19e9b1 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c > @@ -189,6 +189,7 @@ err_cleanup: > static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev, > const struct of_endpoint *ep) > { > + struct drm_bridge *bridge; > struct device_node *np; > int ret; > > @@ -200,8 +201,21 @@ static int fsl_dcu_attach_endpoint(struct > fsl_dcu_drm_device *fsl_dev, > ret = fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel); > if (ret) > return -EPROBE_DEFER; > + return 0; > } > > + bridge = of_drm_find_bridge(np); > + of_node_put(np); > + if (!bridge) > + return -ENODEV; > + > + fsl_dev->encoder.bridge = bridge; > + bridge->encoder = _dev->encoder; > + > + ret = drm_bridge_attach(fsl_dev->drm, bridge); > + if (ret) > + return -EPROBE_DEFER; Just return whatever drm_bridge_attach is returning. -- Stefan > + > return 0; > }
[PATCH -next] gpu: i915: fix build errors when ACPI is not enabled
From: Randy DunlapFix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister' [-Werror=implicit-function-declaration] intel_opregion_unregister(dev_priv); ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume': ../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of function 'intel_opregion_register' [-Werror=implicit-function-declaration] intel_opregion_register(dev_priv); Signed-off-by: Randy Dunlap Cc: Daniel Vetter Cc: Jani Nikula Cc: intel-gfx at lists.freedesktop.org Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/i915/i915_drv.h |2 ++ 1 file changed, 2 insertions(+) --- linux-next-20160624.orig/drivers/gpu/drm/i915/i915_drv.h +++ linux-next-20160624/drivers/gpu/drm/i915/i915_drv.h @@ -3694,6 +3694,8 @@ extern int intel_opregion_notify_adapter extern int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv); #else static inline int intel_opregion_setup(struct drm_i915_private *dev) { return 0; } +static inline void intel_opregion_register(struct drm_i915_private *dev_priv) { } +static inline void intel_opregion_unregister(struct drm_i915_private *dev_priv) { } static inline void intel_opregion_init(struct drm_i915_private *dev) { } static inline void intel_opregion_fini(struct drm_i915_private *dev) { } static inline void intel_opregion_asle_intr(struct drm_i915_private *dev_priv)