Re: [PATCH 1/2] dma-fence: Flag when a fence-array is using signal-on-any

Am 17.02.2017 um 19:35 schrieb Chris Wilson: Indicate that the fence array will be signaled on the first completion (signal-on-any mode) as opposed to waiting for all to be signaled. Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo

[Bug 99843] Geometry Shader - Incorrect Output

https://bugs.freedesktop.org/show_bug.cgi?id=99843 --- Comment #8 from d...@jerber.co.uk --- The hardware is Radeon HD 4890. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[PATCH trivial 3/4] drm/amd: Spelling s/SDMA_WRTIE_SUB_OPCODE_TILED/SDMA_WRITE_SUB_OPCODE_TILED/

Signed-off-by: Geert Uytterhoeven Cc: Alex Deucher Cc: Christian König Cc: dri-devel@lists.freedesktop.orgamd-...@lists.freedesktop.org --- drivers/gpu/drm/amd/amdgpu/cikd.h | 2 +- drivers/gpu/drm/radeon/cikd.h

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: > > The device tree is a representation of the hardware itself. The state > > of the driver support doesn't change the hardware you're running on, > > just like your BIOS/UEFI on x86 won't change the device it reports to > > Linux based on

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

On 02/18/2017 01:22 AM, Christian König wrote: > Am 17.02.2017 um 08:11 schrieb Joe Perches: >> To enable eventual removal of pr_warning >> >> This makes pr_warn use consistent for drivers/gpu >> >> Prior to this patch, there were 15 uses of pr_warning and >> 20 uses of pr_warn in drivers/gpu >>

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote: [...] > We already have DT bindings for out of tree drivers, there's really > nothing new here. We have DT bindings for *hardware*, not for drivers. As stated in Documentation/devicetree/usage-model.txt: "The "Open Firmware Device

[drm] bea5b158ff BUG: unable to handle kernel NULL pointer dereference at 0000000000000748

0- 1 Add linux-next specific files for 20170217 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/lkp Intel Corporation dmesg-quantal-vp-95:20170218095527:x86_64-randconfig-ne0-02160954:4.8.0-rc4-00

Re: [PATCH 2/2] drm/ast: Support AST2500

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote: > Hi Ben, .../... > Not sure why you opted for splitting each suggestion in separate > email, but it seems to have lead to a [serious] bugfix to go > unnoticed. Many thanks for your reviews. I've put a tentative new series there

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

https://bugzilla.kernel.org/show_bug.cgi?id=194579 --- Comment #9 from PaX Team (pagee...@freemail.hu) --- would the following workaround do the job of not triggering the overflow and not causing any other logic bugs for our purposes: --- a/drivers/gpu/drm/ttm/ttm_bo.c 2016-12-13

[Bug 99843] Geometry Shader - Incorrect Output

https://bugs.freedesktop.org/show_bug.cgi?id=99843 --- Comment #7 from Ilia Mirkin --- FWIW it appears to render correctly on both nouveau (GK208) as well as i965 (SKL). -- You are receiving this mail because: You are the assignee for the

[Bug 99843] Geometry Shader - Incorrect Output

https://bugs.freedesktop.org/show_bug.cgi?id=99843 --- Comment #6 from Tom St Denis --- What hardware is this on? I wonder if it's a dup of 99850 (which was found on a Carrizo). -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 2/2] drm/ast: Support AST2500

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote: > > Heh ok. I don't want to change that POST code too much as I'm not > > equipped to test it, but I'll have a look later today. > > > > Not sure why you opted for splitting each suggestion in separate > email, but it seems to have lead to a

Re: [PATCH 2/2] drm/ast: Support AST2500

Hi Ben, On 16 February 2017 at 21:09, Benjamin Herrenschmidt wrote: > On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: >> On 16 February 2017 at 09:09, Benjamin Herrenschmidt >> wrote: >> > From: "Y.C. Chen" >> >

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hi Maxime, As I feared things have taken a turn for the bitter end :-] It seems that this is a heated topic, so I'l kindly ask that we try the following: - For people such as myself/Tobias/others who feel that driver and DT bindings should go hand in hand, prove them wrong. But please, do so

Re: [PULL] mxsfb fixes

On 17 February 2017 at 18:00, Marek Vasut wrote: > On 02/17/2017 03:41 AM, Dave Airlie wrote: >> On 16 February 2017 at 08:16, Marek Vasut wrote: >>> Hi, >>> >>> I collected the MXSFB fixes, based on top of airlied/drm-fixes: >> >> At this stage I'd rather not give

Re: [PATCH 02/14] drm: qxl: Consolidate bo reservation when pinning

Hi Gabriel, 2017-02-15 Gabriel Krisman Bertazi : > Every attempt to pin/unpin objects in memory requires > qxl_bo_reserve/unreserve calls around the pinning operation to protect > the object from concurrent access, which causes that call sequence to be > reproduced every

Re: [PATCH 01/14] drm: qxl: Drop device flags attribute

Hi Gabriel, 2017-02-15 Gabriel Krisman Bertazi : > There are no device specific flags that we need to keep track of here. > Let it vanish. > > Signed-off-by: Gabriel Krisman Bertazi > --- > drivers/gpu/drm/qxl/qxl_drv.c | 2 +- >

[PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array

The code currently assumes that all fence arrays it sees are the normal signal-on-all variety, and decomposes the array into its individual fences so that it can extract the native i915 fences. If the fence array is using signal-on-any, we should not decompose as we must not wait on them all, just

[PATCH 1/2] dma-fence: Flag when a fence-array is using signal-on-any

Indicate that the fence array will be signaled on the first completion (signal-on-any mode) as opposed to waiting for all to be signaled. Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Daniel Vetter

[PATCH 3/9] gpu: ipu-v3: add driver for Prefetch Resolve Engine

This adds support for the i.MX6 QuadPlus PRE units. Currently only linear prefetch into SRAM is supported, other modes of operation like the tiled-to-linear conversion will be added later. Signed-off-by: Lucas Stach --- drivers/gpu/ipu-v3/Makefile | 2 +-

[PATCH 7/9] gpu: ipu-v3: hook up PRG unit

The i.MX6 QuadPlus IPU needs to PRG unit to gain access to the data bus. Make sure it is present and available to be used. Signed-off-by: Lucas Stach --- drivers/gpu/ipu-v3/ipu-common.c | 7 +++ drivers/gpu/ipu-v3/ipu-prv.h| 1 + 2 files changed, 8 insertions(+)

[PATCH 8/9] drm/imx: enable/disable PRG on CRTC enable/disable

On i.MX6 QuadPlus the PRG needs to be clocked in order to pass through the data access requests from the IDMAC. This call is a no-op for other all other SoCs. Signed-off-by: Lucas Stach --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH 9/9] drm/imx: use PRG/PRE when possible

Allow the planes to use the PRG/PRE units as linear prefetchers when possible. This improves DRAM efficiency a bit and reduces the chance for display underflow when the memory subsystem is under load. This does not yet support scanning out tiled buffers directly, as this needs more work, but it

[PATCH 4/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Gasket

This adds the the devicetree binding for the Prefetch Resolve Gasket, as found on i.MX6 QuadPlus. The PRG is fairly simple in that it only has a configuration register range and two clocks, one for the AHB slave port and one for the AXI ports and the functional units. The PRE connections need to

[PATCH 2/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine

The Prefetch Resolve Engine is a prefetch and tile resolve engine which prefetches display data from DRAM to an internal SRAM region. It has a single clock for configuration register access and the functional units. A single shared interrupt is used for status and error signaling. The only

[PATCH 5/9] gpu: ipu-v3: add driver for Prefetch Resolve Gasket

This adds support for the i.MX6 QUadPlus PRG unit. It glues together the IPU and the PRE units. Signed-off-by: Lucas Stach --- drivers/gpu/ipu-v3/Makefile | 2 +- drivers/gpu/ipu-v3/ipu-prg.c | 413 +++

[PATCH 6/9] gpu: ipu-v3: extend the IPUv3 DT binding for i.MX6 QuadPlus

On i.MX6 QuadPlus the IPU needs to know which PRG has to be used for this IPU instance. Add a "fsl,prg" property containing a phandle pointing to the correct PRG device. Signed-off-by: Lucas Stach --- Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 ++

[PATCH 0/9] ipu-v3/imx-drm PRG/PRE extension

Hi all, this is the first round of patches to enable the Prefetch Resolve Gasket and the Prefetch Resolve Engine as found on the i.MX6 QuadPlus. Basically those units are external extensions to the IPUv3 that are able to prefetch display data from DRAM to an internal SRAM region, transforming the

[PATCH 1/9] gpu: ipu-v3: remove AXI ID setting for IC channel

This is a pretty minor optimization for the IC channel to get out-of-order AXI returns, but clashes with the AXI ID assignment that needs to be done for the display channels on QuadPlus. Signed-off-by: Lucas Stach --- drivers/gpu/ipu-v3/ipu-image-convert.c | 2 -- 1 file

Re: [Nouveau] nouveau preventing shutdown after suspend-resume

On 17.02.2017 18:06, Ilia Mirkin wrote: > On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita > wrote: >> Hello Ilia, >> >> On 17 February 2017 at 11:14, Ilia Mirkin wrote: >>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita >>>

[Bug 99850] Tessellation bug on Carrizo

https://bugs.freedesktop.org/show_bug.cgi?id=99850 --- Comment #2 from Tom St Denis --- Dug up the original thread that introduced this patch. Might prove useful in debugging it. https://lists.freedesktop.org/archives/mesa-dev/2016-May/116152.html -- You are receiving

Re: nouveau preventing shutdown after suspend-resume

On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita wrote: > Hello Ilia, > > On 17 February 2017 at 11:14, Ilia Mirkin wrote: >> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita >> wrote: >>> I'm happy to file >>> a bugzilla

[Bug 99843] Geometry Shader - Incorrect Output

https://bugs.freedesktop.org/show_bug.cgi?id=99843 --- Comment #5 from d...@jerber.co.uk --- Created attachment 129697 --> https://bugs.freedesktop.org/attachment.cgi?id=129697=edit Trace -- You are receiving this mail because: You are the assignee for the

[Bug 99843] Geometry Shader - Incorrect Output

https://bugs.freedesktop.org/show_bug.cgi?id=99843 --- Comment #4 from d...@jerber.co.uk --- I created a minimal test program that simply draws the 3 polygons (12 sided). I have used apitrace with this test program to generate a trace and I'll upload this shortly. Thanks. -- You are receiving

Re: nouveau preventing shutdown after suspend-resume

Hello Ilia, On 17 February 2017 at 11:14, Ilia Mirkin wrote: > On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita > wrote: >> I'm happy to file >> a bugzilla entry and provide any other needed information or help with >> testing. Are nouveau bugs

Re: nouveau preventing shutdown after suspend-resume

On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita wrote: > I'm happy to file > a bugzilla entry and provide any other needed information or help with > testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo > bugzilla? Nouveau bugs are tracked on the fdo

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Alexandre Belloni wrote: > On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote: >>> The device tree is a representation of the hardware itself. The state >>> of the driver support doesn't change the hardware you're running on, >>> just like your BIOS/UEFI on x86 won't change the device it reports

nouveau preventing shutdown after suspend-resume

Hello, I'm working on a Asus X756UQK laptop with nvidia + intel graphics cards. After a suspend-resume cycle, the machine hangs on shutdown, requiring a forced power off. After resuming I sometimes see the following messages on the kernel log: [ 186.117539] nouveau :01:00.0: DRM:

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Thu, Feb 16, 2017 at 04:54:45PM +, Emil Velikov wrote: > On 16 February 2017 at 12:43, Tobias Jakobi > wrote: > > Hello, > > > > I was wondering about the following. Wasn't there some strict > > requirement about code going upstream, which also included that

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 01:45:44PM +0100, Tobias Jakobi wrote: > Hello Maxime, > > Maxime Ripard wrote: > > Hi, > > > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: > >> I was wondering about the following. Wasn't there some strict > >> requirement about code going upstream,

[Bug 99850] Tessellation bug on Carrizo

https://bugs.freedesktop.org/show_bug.cgi?id=99850 Bug ID: 99850 Summary: Tessellation bug on Carrizo Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal

[Bug 99850] Tessellation bug on Carrizo

https://bugs.freedesktop.org/show_bug.cgi?id=99850 --- Comment #1 from Tom St Denis --- Created attachment 129693 --> https://bugs.freedesktop.org/attachment.cgi?id=129693=edit Carrizo run with HEAD~ -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 0/4] drm: handle override/firmware edid at the lowest level

On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote: > v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com lgtm. For the series Reviewed-by: Ville Syrjälä -- Ville Syrjälä Intel OTC

Re: [PATCH] drm: add drm_get_connector_force_name

On Fri, Feb 17, 2017 at 05:14:47PM +0200, Jani Nikula wrote: > Follow the naming in debugfs also for logging, add "unknown" for values > beyond the enumerated ones. > > Signed-off-by: Jani Nikula > --- > +EXPORT_SYMBOL(drm_get_connector_force_name); Do we need the symbol

Re: [PATCH v2] drm/color: Document CTM eqations

On Fri, Feb 17, 2017 at 03:05:28PM +, Lionel Landwerlin wrote: > On 17/02/17 14:56, Ville Syrjälä wrote: > > On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote: > >> On 17/02/17 13:54, Brian Starkey wrote: > >>> What's the verdict? We've got [1] which is about to become another

[PATCH v2 3/4] drm/edid: respect connector force for drm_get_edid ddc probe

Skip DDC probe for forced connector status. Don't try to read the EDID if the connector is forced off. Skipping probe for forced on connectors will make more sense when drm_do_get_edid() will handle override and firmware EDIDs. Suggested-by: Ville Syrjälä

[PATCH v2 1/4] drm: move edid property update and add modes out of edid firmware loader

Make the firmware loader more generic and generally useful. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid_load.c| 17 - drivers/gpu/drm/drm_probe_helper.c | 8 +++- include/drm/drm_edid.h | 7 --- 3 files changed, 15

[PATCH v2 2/4] drm: do not debug log about missing CEA extensions on NULL edid

Make the drm_edid_to_eld() function useful for resetting, not just setting, the ELD and HDMI VSDB data, without debug warnings about missing CEA extensions. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

Handle debugfs override edid and firmware edid at the low level to transparently and completely replace the real edid. Previously, we practically only used the modes from the override EDID, and none of the other data. This also prevents actual EDID reads when the EDID is to be overridden, but

Re: [PATCH v2] drm/color: Document CTM eqations

Hi, On 17 February 2017 at 14:56, Ville Syrjälä wrote: > On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote: >> If we're talking fixed point reprsentation, ChromeOS is using this : >> >>

[PATCH] drm: add drm_get_connector_force_name

Follow the naming in debugfs also for logging, add "unknown" for values beyond the enumerated ones. Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_connector.c | 41 + drivers/gpu/drm/drm_debugfs.c | 24 +---

Re: [PATCH v2] drm/color: Document CTM eqations

On 17/02/17 14:56, Ville Syrjälä wrote: On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote: On 17/02/17 13:54, Brian Starkey wrote: What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I

Re: [PATCH v2] drm/color: Document CTM eqations

On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote: > On 17/02/17 13:54, Brian Starkey wrote: > > What's the verdict? We've got [1] which is about to become another > > (driver) implementation - better to change before that merges than > > after I guess. > > > > -Brian > > > > [1]

Re: [PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

Am 17.02.2017 um 08:11 schrieb Joe Perches: To enable eventual removal of pr_warning This makes pr_warn use consistent for drivers/gpu Prior to this patch, there were 15 uses of pr_warning and 20 uses of pr_warn in drivers/gpu Signed-off-by: Joe Perches Acked-by:

Re: [PATCH v2] drm/color: Document CTM eqations

On 17/02/17 13:54, Brian Starkey wrote: What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I guess. -Brian [1] https://lkml.org/lkml/2017/2/13/304 On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone

[PATCH v1 1/2] of: add devm_ functions for populate and depopulate

Lost of calls to of_platform_populate() are not unbalanced by a call to of_platform_depopulate(). This create issues while drivers are bind/unbind. In way to solve those issues is to add devm_of_platform_populate() which will call of_platform_depopulate() when the device is unbound from the bus.

[PATCH v1 0/2] Introduce devm_of_platform_populate() helper

Lost of calls to of_platform_populate() are not unbalanced by a call to of_platform_depopulate(). This create issues while drivers are bind/unbind. In way to solve those issues is to add devm_of_platform_populate() which will call of_platform_depopulate() when the device is unbound from the

[PATCH v1 2/2] drm: sti: make driver use devm_of_platform_populate()

This make sure that of_platform_depopulate() is called if an error occur in probe after populating the date from the device tree. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

On Fri, Feb 17, 2017 at 04:02:02PM +0200, Jani Nikula wrote: > On Thu, 16 Feb 2017, Ville Syrjälä wrote: > > On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote: > >> Make the function useful for resetting, not just setting, the ELD. > >> > >>

Re: [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

On Thu, 16 Feb 2017, Ville Syrjälä wrote: > On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote: >> Make the function useful for resetting, not just setting, the ELD. >> >> Signed-off-by: Jani Nikula >> --- >>

Re: [PATCH v2] drm/color: Document CTM eqations

What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I guess. -Brian [1] https://lkml.org/lkml/2017/2/13/304 On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote: Hi, On 15 February 2017 at 11:39,

[GIT PULL FOR v4.12] Bye bye drm_platform midlayer

Hi Dave, The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c: Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000) are available in the git repository at: git://linuxtv.org/pinchartl/media.git drm/next/platform for you to fetch changes up to

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >

[PATCH 2/7] drm/sun4i: Fix up error path cleanup for master bind function

The master bind function calls numerous drm functions which initialize underlying structures. It also tries to bind the various components of the display pipeline, some of which may add additional drm objects. This patch adds proper cleanup functions in the error path of the master bind function.

[PATCH 0/7] drm/sun4i: Various fixes and cleanups part 1

Hi Maxime, This is the first bunch of fixes for the sun4i drm driver. This is part of the cleanup I am doing towards making the driver support multiple display pipelines. Patch 1 moves the drm_mode_config_cleanup call from sun4i_framebuffer_free to be called directly in sun4i_drv_unbind. This is

[PATCH 7/7] drm/sun4i: Make sun4i_crtc_init return ERR_PTR style error codes

sun4i_crtc_init can fail for a number of reasons. Instead of returning a NULL pointer when it fails, pass back the encountered error using ERR_PTR. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 ++-- drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++-- 2 files

[PATCH 1/7] drm/sun4i: Move drm_mode_config_cleanup call to main driver

drm_mode_config_cleanup is the complement of drm_mode_config_init, which is called in the bind function of sun4i_drv. drm_mode_config_cleanup should be put in the unbind function to match. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +

[PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done

[PATCH 4/7] drm/sun4i: Fix kcalloc element size in sun4i_layers_init

In sun4i_layers_init we are allocating an array of pointers to struct sun4i_layer: layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes), sizeof(**layers), GFP_KERNEL); The element size should be the size of an individual element of the array.

Re: [PULL] mxsfb fixes

On 02/17/2017 03:41 AM, Dave Airlie wrote: > On 16 February 2017 at 08:16, Marek Vasut wrote: >> Hi, >> >> I collected the MXSFB fixes, based on top of airlied/drm-fixes: > > At this stage I'd rather not give these to Linus, can you rebase them onto > drm-next, and resend, feel

[PATCH 3/7] drm/sun4i: Check return value of drm_vblank_init

drm_vblank_init can fail due to insufficient memory. Ignoring the error and proceeding may cause the kernel to dereference an invalid pointer when vblank is enabled. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_drv.c | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH] backport commit bb98e72adaf9d19719aba35f802d4836f5d5176c to 4.4.49 fixed i915 dsi init bug passed test on my Lenovo Miix 2 8 (Bay Trail Z3740)

commit bb98e72adaf9d19719aba35f802d4836f5d5176c Author: Hans de Goede Date: Fri Dec 2 15:29:04 2016 +0100 drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on

[PATCH 5/7] drm/sun4i: Drop useless assignment in sun4i_layers_init

The assignment found in the main loop in sun4i_layers_init: struct sun4i_layer *layer = layers[i]; is useless as it gets overwritten by the next line: layer = sun4i_layer_init_one(drm, plane); Drop the assignment. Signed-off-by: Chen-Yu Tsai ---

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

Hi Rafael, On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki wrote: > On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: >> There are ~4300 uses of pr_warn and ~250 uses of the older >> pr_warning in the kernel source tree. >> >> Make the use of pr_warn

[PATCH 6/7] drm/sun4i: Save newly created layer in layers array in sun4i_layers_init

sun4i_layers_init allocates an array to store pointers to newly created layers returned by sun4i_layer_init_one(), but fails to actually store them. But it actually returns the empty array to unsuspecting users. Save the pointers in the array, so that they may be used later. Signed-off-by:

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On 17 February 2017 at 12:45, Tobias Jakobi wrote: > Hello Maxime, > > Maxime Ripard wrote: >> Hi, >> >> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >>> I was wondering about the following. Wasn't there some strict >>> requirement about code going

KMS backlight ABI proposition

Hey everyone, We have been working towards exposing the backlight as a KMS property instead of relying on the backlight drivers. We have CC:ed the people we have found to be the more likely to be interested in the discussion but please add everyone you think would have some experience with

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote: >> Hello, >> >> I'm not sure if I'm missing something here, but I don't see how this is >> supposed to work. >> >> This just multiplies the height of the drm_mode_fb_cmd2 object with the

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >> I was wondering about the following. Wasn't there some strict >> requirement about code going upstream, which also included that there >> was a full open-source driver stack for it? >>

Re: [Intel-gfx] [PATCH v3 6/6] drm/i915: allow HDMI 2.0 clock rates

On Fri, 2017-02-10 at 21:59 +0530, Shashank Sharma wrote: > Geminilake has a native HDMI 2.0 controller, which is capable of > driving clocks upto 594Mhz. This patch updates the max tmds clock > limit for the same. > > V2: rebase > V3: rebase > > Cc: Ander Conselvan De Oliveira

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hi Maxime, On Wednesday 15 Feb 2017 13:51:29 Maxime Ripard wrote: > On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote: > > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > >> On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote: > >>> On 13 February 2017 at 10:54,

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hi Maxime, On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +, Daniel Stone wrote: > > On 13 February 2017 at 10:54, Maxime Ripard wrote: > >> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >>> On Thursday 02 Feb 2017 11:31:56

[GIT PULL] imx-drm: TVE regulator, fb size limit, and ipu-v3 module fixes

Hi Dave, this tag has a few IPUv3 fixes that are helpful for the ongoing i.MX media driver development, a fix for the i.MX53 TV encoder on device trees that don't set the regulator property, and a patch to drop the arbitrary minimum framebuffer size limit of 64x64 pixels. regards Philipp The

[PATCH v3 0/3] video/sti/cec: add HPD notifier support

This patch series following what Hans is doing on exynos to support hotplug detect notifier code. It add support of HPD in sti_hdmi drm driver and stih-cec driver which move out of staging. Those patches should be applied on top of Hans branch exynos4-cec. I have tested hdmi notifier by

[PATCH v3 2/3] stih-cec: add HPD notifier support

By using the HPD notifier framework there is no longer any reason to manually set the physical address. This was the one blocking issue that prevented this driver from going out of staging, so do this move as well. Update the bindings documentation the new hdmi phandle. Signed-off-by: Benjamin

[PATCH v3 3/3] arm: sti: update sti-cec for HPD notifier support

To use HPD notifier sti CEC driver needs to get phandle of the hdmi device. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil CC: devicet...@vger.kernel.org version 3: - change hdmi phandle from "st,hdmi-handle" to "hdmi-handle"

[PATCH v3 1/3] sti: hdmi: add HPD notifier support

Implement the HPD notifier support to allow CEC drivers to be informed when there is a new EDID and when a connect or disconnect happens. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil --- drivers/gpu/drm/sti/Kconfig| 1 +

Re: [PATCH 1/9] drm/ast: Handle configuration without P2A bridge

On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote: > The ast driver configures a window to enable access into BMC > memory space in order to read some configuration registers. Aspeed suggested a couple of refinements for some chipsets, so I'll respin either this week-end or monday.

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: Hi, On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

https://bugzilla.kernel.org/show_bug.cgi?id=194579 --- Comment #8 from Christian König (deathsim...@vodafone.de) --- (In reply to Nicolai Hähnle from comment #7) > Therefore, I'm inclined to say that this is probably not an actual bug. Yeah, correct. The calculated offset is never used, so the

[PULL] drm-intel-next-fixes

Hi Dave, i915 and GVT fixes for the v4.11 merge window. There's quite a bit of cc: stable stuff that either didn't apply cleanly to v4.10 or just arrived too late. I played it safe, and didn't try to rush them to v4.10 anymore. This one superseeds [1]. I rebased/recreated the branch to get rid

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hi, On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote: > Hello, > > I'm not sure if I'm missing something here, but I don't see how this is > supposed to work. > > This just multiplies the height of the drm_mode_fb_cmd2 object with the > number of buffers. Let's say I have

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hi, On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: > I was wondering about the following. Wasn't there some strict > requirement about code going upstream, which also included that there > was a full open-source driver stack for it? > > I don't see how this is the case for Mali,

Re: [PULL] drm-misc-next-fixes, take 2

On Fri, 17 Feb 2017, Dave Airlie wrote: > On 16 February 2017 at 19:49, Jani Nikula wrote: >> >> Hi Dave, this one superseeds [1]. Better to flush out the single uapi >> fix for v4.11 now so it's not forgotten. > > Looks like I had already pulled, I just