[PATCH libdrm 3/3] xf86drm: don't fatal on per device error in drmGetDevice[s]2

On Mon, Dec 12, 2016 at 02:12:28PM +, Emil Velikov wrote: > On 10 December 2016 at 05:52, Jonathan Gray wrote: > > When iterating over all the device nodes if drmProcessPciDevice() > > returned an error for any node the function would return an error, > > ignoring any valid nodes. > > > > The

[PATCH libdrm 1/3] xf86drm: adjust device node path for minor base

On Mon, Dec 12, 2016 at 02:10:31PM +, Emil Velikov wrote: > On 10 December 2016 at 05:52, Jonathan Gray wrote: > > When constructing a path to a device node the minor number retrieved > > from fstat needs to have the offset of the node type subtracted from it. > > Control and render node

[PATCH v3 08/20] drm: omapdrm: Handle OCP error IRQ directly

Hi Tomi, On Tuesday 20 Sep 2016 16:34:37 Tomi Valkeinen wrote: > On 19/09/16 15:27, Laurent Pinchart wrote: > > Instead of going through a complicated registration mechanism, just > > call the OCP error IRQ handler directly from the main IRQ handler. > > > > Signed-off-by: Laurent Pinchart > >

[PATCH v3 09/20] drm: omapdrm: Replace DSS manager state check with omapdrm CRTC state

Hi Tomi, On Tuesday 20 Sep 2016 16:44:21 Tomi Valkeinen wrote: > On 19/09/16 15:27, Laurent Pinchart wrote: > > Instead of conditioning planes update based on the DD manager state, use > > s/DD/DSS/ > > Maybe "manager HW state" to highlight that the status is read from a HW > register. I'll

[PATCH v3 10/20] drm: omapdrm: Only commit planes on active CRTCs

Hi Tomi, On Tuesday 20 Sep 2016 16:51:11 Tomi Valkeinen wrote: > On 19/09/16 15:27, Laurent Pinchart wrote: > > The DRM core supports skipping plane update for inactive CRTCs for > > hardware that don't need it or can't cope with it. That's our case, so > > use the DRM core infrastructure instead

[PATCH v3 11/20] drm: omapdrm: Check DSS manager state in the enable/disable helpers

Hi Tomi, On Tuesday 20 Sep 2016 16:57:59 Tomi Valkeinen wrote: > On 19/09/16 15:27, Laurent Pinchart wrote: > > The omapdrm DSS manager enable/disable operations check the DSS manager > > state to avoid double enabling/disabling. Move that code to the DSS > > manager to decrease the dependency of

[PATCH v3 18/20] drm: omapdrm: Make pipe2vbl function static

Hi Tomi, On Monday 12 Dec 2016 12:41:11 Tomi Valkeinen wrote: > On 19/09/16 15:27, Laurent Pinchart wrote: > > The function is only used in omap_irq.c, move it there and make it > > static. > > > > Signed-off-by: Laurent Pinchart > > --- > > > > drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ---

[PATCH libdrm] xf86drm: fix aliasing violation

On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov wrote: > On 11 December 2016 at 18:03, Grazvydas Ignotas wrote: >> Just tell the compiler that drm_event will alias the char buffer, >> so that it has no excuse to warn or generate bad code. >> > Afacit this patch [1] from Thierry should correctly

[PATCH 1/1] drm/amd/amdgpu: get maximum and used UVD handles (v3)

From: Arindam Nath Change History -- v3: changes suggested by Christian - Add a check for UVD IP block using AMDGPU_HW_IP_UVD query type. - Add a check for asic_type to be less than CHIP_POLARIS10 since starting Polaris, we support unlimited UVD

[PATCH] amdgpu: get maximum and used UVD handles

From: Arindam Nath User might want to query the maximum number of UVD instances supported by firmware. In addition to that, if there are multiple applications using UVD handles at the same time, he might also want to query the currently used number of handles. For this we

[git pull] drm tree for 4.10

Hi Linus, This is the main drm pull request for the 4.10. Posting it early as I'm probably on holidays for next few days. Items of note: There is a big chunk of AMD register headers in here that bumps the size quite a bit. Renaming the dma-buf fence to dma_fence which is a more apt naming.

[PATCH] drm_fourcc: Document linear modifier

; + > /* Intel framebuffer modifiers */ > > /* > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/91da45fe/attachment.html>

[RFC] Using DC in amdgpu for upcoming GPU

> We would love to upstream DC for all supported asic! We made enough change > to make Sea Island work but it's really not validate to the extend we > validate Polaris on linux and no where close to what we do for 2017 ASICs. > With DC the display hardware programming, resource optimization,

[RFC PATCH 0/3] staging: remove fbdev drivers

On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: >>> As for multi userspace client, well, swapping an mmap between HW and >>> memory backing store is a somewhat solved problem already. >> >> Hm, I didn't know that, but then all existing

[PATCH] drm_fourcc: Document linear modifier

On Tue, Dec 13, 2016 at 05:32:29AM +, Kristian Høgsberg wrote: > Did we forget about this one? I guess I could commit it myself, but I'm not > sure which branch to push it too... Indeed this got lost, applied to drm-misc now. -Daniel > > Kristian > > On Wed, Nov 9, 2016 at 4:10 PM

Issue with DRM and "reimplement IDR and IDA using the radix tree"

t IDR and IDA using the radix tree" on 20161213's next fixes the issue for me, suggesting a bug may have slipped in there. Not sure how this could be fixed, so reporting the issue for now in case it is not known yet. Cheers, Alex.

[RFC] Using DC in amdgpu for upcoming GPU

(hit send too early) > We would love to upstream DC for all supported asic! We made enough change > to make Sea Island work but it's really not validate to the extend we > validate Polaris on linux and no where close to what we do for 2017 ASICs. > With DC the display hardware programming,

[RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 09:33:52PM -0500, Harry Wentland wrote: > On 2016-12-11 03:28 PM, Daniel Vetter wrote: > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > > > We propose to use the Display Core (DC) driver for display support on > > > AMD's upcoming GPU (referred to by

[RFC] Using DC in amdgpu for upcoming GPU

On 10/12/16 01:32 AM, Jan Ziak wrote: > Hello Dave > > Let's cool down the discussion a bit and try to work out a solution. > > To summarize the facts, your decision implies that the probability of > merging DAL/DC into the mainline Linux kernel the next year (2017) has > become extremely low. >

[RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 11:10:30PM -0500, Cheng, Tony wrote: > Thanks for the write up for the guide. We can definitely re-do atomic > according to guideline provided as I am not satified with how our code look > today. To me it seems more like we need to shuffle stuff around and rename > a few

[PATCH v3 10/20] drm: omapdrm: Only commit planes on active CRTCs

-- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/edf409e9/attachment.sig>

[PATCH v3 11/20] drm: omapdrm: Check DSS manager state in the enable/disable helpers

which might lead to issues. > > That's correct, but the DRM core nowadays should really guarantee that CRTCs > won't be enabled or disabled multiple times. Ok. So we could probably add a dev_warn() there, as getting that state wrong might cause issues that are difficult to debug. It would be best to check the HW state, but if you want to remove the call to dispc, I guess just checking omap_crtc->enabled is good enough. The comment for omap_crtc_set_enabled talks about suspend/resume. Perhaps at some point it was called from suspend/resume, even for crtcs that were already disabled, which would explain the need for the check. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/4c8f8b43/attachment.sig>

[RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 09:05:15PM -0500, Harry Wentland wrote: > > On 2016-12-12 02:22 AM, Daniel Vetter wrote: > > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote: > > > Current version of DC: > > > > > > * > > >

[PATCH 1/4] drm: Protect master->unique with dev->master_mutex

On Mon, Dec 12, 2016 at 01:23:46PM +, Emil Velikov wrote: > On 10 December 2016 at 21:52, Daniel Vetter wrote: > > No one looks at the major/minor versions except the unique/busid > > stuff. If we protect that with the master_mutex (since it also affects > > the unique of each master, oh

[GIT PULL] fbdev changes for 4.10

-- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/5d078049/attachment-0001.sig>

[Intel-gfx] [PATCH 3/4] drm: Enforce BKL-less ioctls for modern drivers

On Mon, Dec 12, 2016 at 09:50:29AM +, Chris Wilson wrote: > On Sat, Dec 10, 2016 at 10:52:54PM +0100, Daniel Vetter wrote: > > With the last round of changes all ioctls called by modern drivers now > > have their own locking. Everything else is only allowed for legacy > > drivers and hence the

[PATCH 1/4] drm: Protect master->unique with dev->master_mutex

On Mon, Dec 12, 2016 at 09:39:55AM +, Chris Wilson wrote: > On Sat, Dec 10, 2016 at 10:52:52PM +0100, Daniel Vetter wrote: > > No one looks at the major/minor versions except the unique/busid > > stuff. If we protect that with the master_mutex (since it also affects > > the unique of each

[PATCH] drm: shmobile: Perform initialization/cleanup at probe/remove time

On Mon, Dec 12, 2016 at 11:08:48PM +0200, Laurent Pinchart wrote: > The drm driver .load() operation is prone to race conditions as it > initializes the driver after registering the device nodes. Its usage is > deprecated, inline it in the probe function and call drm_dev_alloc() and >

[PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node

remote-endpoint = <_bridge_in>; }; }; }; Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/5ebeac17/attachment.sig>

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi, > The acceleration that most of the 2D things provide isn't ever that > great, and shadowing is a lot more effective if done properly. That is probably true for anything pci-ish, because those devices are optimized for memory writes and reads are horribly slow. So you surely want avoid

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi, > Well, I had that argument with Dave Airlie which I CCed. The "dumb" ones like > bochsdrmfb, cirrusdrmfb, astdrmfb ... all use shadowing, meaning they use a > lot more memory and cannot do any 2D acceleration for fbcon. Well, at least for cirrusdrmfb using 2d accel is kida pointless as

[Bug 99045] The string passed to sscanf() contains an uninitialized value.

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161213/a3805f91/attachment.html>

[git pull] drm tree for 4.10

On Tue, Dec 13, 2016 at 03:20:07PM +1000, Dave Airlie wrote: > Hi Linus, > > This is the main drm pull request for the 4.10. Posting it early as I'm > probably > on holidays for next few days. > > Items of note: > There is a big chunk of AMD register headers in here that bumps the > size quite

[RFC] Using DC in amdgpu for upcoming GPU

On 12/13/2016 2:30 AM, Dave Airlie wrote: > (hit send too early) >> We would love to upstream DC for all supported asic! We made enough change >> to make Sea Island work but it's really not validate to the extend we >> validate Polaris on linux and no where close to what we do for 2017 ASICs.

[RFC 1/5] drm/virtio: add virtio_gpu_alloc_fence()

Hi, > +struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device > *vgdev) > +{ > + struct virtio_gpu_fence_driver *drv = >fence_drv; > + struct virtio_gpu_fence *fence; > + unsigned long irq_flags; > + > + fence = kmalloc(sizeof(struct virtio_gpu_fence),

[PATCH 1/7] drm/hisilicon: Don't set drm_device->platformdev

On Fri, Dec 09, 2016 at 01:04:12PM -0500, Sean Paul wrote: > On Fri, Dec 9, 2016 at 9:19 AM, Daniel Vetter > wrote: > > It's deprecated and only should be used by drivers which still use > > drm_platform_init, not by anyone else. > > > > And indeed it's entirely unused and can be nuked. > > > >

[PATCH 01/34] drm/i915: Use the MRU stack search after evicting

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > When we evict from the GTT to make room for an object, the hole we > create is put onto the MRU stack inside the drm_mm range manager. On the > next search pass, we can speed up a PIN_HIGH allocation by referencing > that stack for the new

[PATCH 02/34] drm/i915: Simplify i915_gtt_color_adjust()

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > If we remember that node_list is a circular list containing the fake > head_node, we can use a simple list_next_entry() and skip the NULL check > for the allocated check against the head_node. > > Signed-off-by: Chris Wilson I'm not sure

[PATCH 03/34] drm: Add drm_mm_for_each_node_safe()

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe() > for walking the list of nodes safe against removal. > > Signed-off-by: Chris Wilson > +#define __drm_mm_nodes(mm) (&(mm)->head_node.node_list) Not static inline

[RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 09:52:08PM -0500, Cheng, Tony wrote: > With DC the display hardware programming, resource optimization, power > management and interaction with rest of system will be fully validated > across multiple OSs. Do I understand DAL3.jpg correctly that the macOS driver builds on

[PATCH 1/4] drm: Protect master->unique with dev->master_mutex

On 13/12/16 05:35 PM, Daniel Vetter wrote: > On Mon, Dec 12, 2016 at 01:23:46PM +, Emil Velikov wrote: >> On 10 December 2016 at 21:52, Daniel Vetter >> wrote: >>> No one looks at the major/minor versions except the unique/busid >>> stuff. If we protect that with the master_mutex (since it

[PATCH 1/4] drm: Protect master->unique with dev->master_mutex

On Tue, Dec 13, 2016 at 10:42 AM, Michel Dänzer wrote: >> Hm, I thought the grand plan is to use -modesetting almost everywhere and >> forget about all the others? > > Maybe if you mean s/grand plan/pipe dream/ ... I said "almost everywhere", not "everywhere". I'm fully aware that there's tons

[PATCH 04/34] drm: Add some kselftests for the DRM range manager (struct drm_mm)

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > First we introduce a smattering of infrastructure for writing selftests. > The idea is that we have a test module that exercises a particular > portion of the exported API, and that module provides a set of tests > that can either be run as

[PATCH v7 0/5] ARM: dts: da850: tilcdc related DT changes

This series contains the last DT changes required for LCDC support on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second limits the maximum pixel clock rate. v1 -> v2: - drop patch 3/3 (already merged) - use max-pixelclock instead of max-bandwidth for display mode limiting v2 ->

[PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node

Add the vga-bridge node to the board DT together with corresponding ports and vga connector. This allows to retrieve the edid info from the display automatically. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- arch/arm/boot/dts/da850-lcdk.dts | 51

[PATCH v7 3/5] drm: bridge: add support for TI ths8135

THS8135 is a configurable video DAC, but no configuration is actually necessary to make it work. For now use the dumb-vga-dac driver to support it. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 + 1 file changed, 1 insertion(+)

[PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135

THS8135 is a configurable video DAC. Add DT bindings for this chip. Signed-off-by: Bartosz Golaszewski Reviewed-by: Laurent Pinchart Acked-by: Rob Herring --- .../bindings/display/bridge/ti,ths8135.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644

[RFC] Using DC in amdgpu for upcoming GPU

scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/e7e9ac39/attachment.html>

[PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

At maximum CPU frequency of 300 MHz the maximum pixel clock frequency is 37.5 MHz[1]. We must filter out any mode for which the calculated pixel clock rate would exceed this value. Specify the max-pixelclock property for the display node for da850-lcdk. [1]

[PATCH v7 1/5] ARM: dts: da850: rename the display node label

The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation. The label is also 'display', but change it to 'lcdc' to make it clear what the underlying hardware is. Signed-off-by: Bartosz Golaszewski --- arch/arm/boot/dts/da850.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 05/34] drm: kselftest for drm_mm_init()

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Simple first test to just exercise initialisation of struct drm_mm. > > Signed-off-by: Chris Wilson > + drm_mm_for_each_hole(hole, , start, end) { > + if (start != 0 || end != 4096) { > + pr_err("empty

[PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node

2016-12-13 9:46 GMT+01:00 Tomi Valkeinen : > Hi, > > On 12/12/16 15:05, Bartosz Golaszewski wrote: > >> + { >> + status = "okay"; >> + pinctrl-names = "default"; >> + pinctrl-0 = <_pins>; >> + >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>;

[PATCH 04/34] drm: Add some kselftests for the DRM range manager (struct drm_mm)

On Tue, Dec 13, 2016 at 11:58:54AM +0200, Joonas Lahtinen wrote: > On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c > > @@ -0,0 +1,47 @@ > > +/* > > + * Test cases for the drm_mm range manager > > + */ > > + > > +#define pr_fmt(fmt) "drm_mm: "

[Intel-gfx] [RESEND PATCH v12] drm/i915/debugfs: Move out pipe CRC code

On Mon, Dec 12, 2016 at 01:29:48PM +0100, Tomeu Vizoso wrote: > In preparation to using a generic API in the DRM core for continuous CRC > generation, move the related code out of i915_debugfs.c into a new file. > > Eventually, only the Intel-specific code will remain in this new file. > > v2:

[Intel-gfx] [PATCH] drm: Fix for invalid pruning of modes in dual display cases

On Tue, 13 Dec 2016, Vidya Srinivas wrote: > Currently in dual display connected boot scenarios, minimum of the resolutions > is taken for fb width and height as reference. Based on this resolution, other > modes are pruned. > > Example Scenario: If DSI mode is 2560x1440 and HDMI is 1920x1080,

[bug report] drm/amdgpu: Add support for CIK parts

Hello Alex Deucher, The patch a2e73f56fa62: "drm/amdgpu: Add support for CIK parts" from Apr 20, 2015, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/ci_dpm.c:6293 ci_dpm_sw_init() warn: 'adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries'

[PATCH 06/34] drm: Add a simple linear congruent generator PRNG

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > For testing, we want a reproducible PRNG, a plain linear congruent > generator is suitable for our very limited selftests. > > Signed-off-by: Chris Wilson > +++ b/drivers/gpu/drm/lib/drm_rand.c > @@ -0,0 +1,51 @@ > +#include > +#include

[Bug 99019] "Star Ruler 2" game will freeze the system

https://www.dropbox.com/s/rje3xylvyablt4p/StarRuler2-trace.xz?dl=0 -- 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/20161213

[Intel-gfx] [PATCH] drm: Fix for invalid pruning of modes in dual display cases

On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote: > Currently in dual display connected boot scenarios, minimum of the resolutions > is taken for fb width and height as reference. Based on this resolution, other > modes are pruned. > > Example Scenario: If DSI mode is 2560x1440 and

[PATCH 1/4] drm/etnaviv: Use drm_dev_unref, not drm_put_dev

Am Donnerstag, den 08.12.2016, 12:07 +0100 schrieb Daniel Vetter: > drm_put_dev is the old midlayer-broken device cleanup function, but > etnaviv has a proper unbind function which first unregisters and then > drops the final reference. No functional change since > drm_dev_unregister happens to be

[PATCH 2/4] drm/fsl: don't use drm_put_dev

Am Donnerstag, den 08.12.2016, 12:07 +0100 schrieb Daniel Vetter: > fsl is already fully demidlayered in the probe function, but for > convenience stuck with drm_put_dev. Call the unregister/unref parts > separately, to make sure this driver works correct. > > Cc: Stefan Agner > Signed-off-by:

[PATCH 3/4] drm/mediatek: don't use drm_put_dev

Am Donnerstag, den 08.12.2016, 12:07 +0100 schrieb Daniel Vetter: > fsl is already fully demidlayered in the probe function, but for ^ mediatek not fsl-dcu > convenience stuck with drm_put_dev. Call the unregister/unref parts > separately, to make sure this driver works correct. > I don't

[PATCH libdrm] xf86drm: fix null termination of string buffer

From: Taro Yamada The string written to the buffer by read() is not null-terminated, but currently drmParsePciBusInfo() places null character only at the end of the buffer, not at the end of the string. As a result, the string passed to sscanf() contains an uninitialized

Patch to fix null termination of string buffer

This is my first time to sending a patch to the mailing list. So, I'm sorry if I did something wrong. The function drmParsePciBusInfo() in xf86drm.c reads the contents of the file "/sys/dev/char/x:y/device/uevent" into the buffer. The string written to the buffer by read() is not

[RFC 1/5] drm/virtio: add virtio_gpu_alloc_fence()

2016-12-13 Gerd Hoffmann : > Hi, > > > +struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct virtio_gpu_device > > *vgdev) > > +{ > > + struct virtio_gpu_fence_driver *drv = >fence_drv; > > + struct virtio_gpu_fence *fence; > > + unsigned long irq_flags; > > + > > + fence =

[RFC] Using DC in amdgpu for upcoming GPU

Hi Harry, I've been loathe to jump in here, not least because both cop roles seem to be taken, but ... On 13 December 2016 at 01:49, Harry Wentland wrote: > On 2016-12-11 09:57 PM, Dave Airlie wrote: >> On 8 December 2016 at 12:02, Harry Wentland >> wrote: >> Sharing code is a laudable goal

[PATCH 23/34] drm: Simplify drm_mm_clean()

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > To test whether there are any nodes allocated within the range manager, > we merely have to ask whether the node_list is empty. > > Signed-off-by: Chris Wilson For documentation purposes add "Since commit ..." to the commit message?

[patch] drm: mxsfb: drm_dev_alloc() returns error pointers

We should be checking for IS_ERR() instead of NULL because drm_dev_alloc() returns error pointers. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index

[PATCH 0/5] sphinxification for dma-buf docs

Thanks Jonathan! On 12 December 2016 at 01:14, Jonathan Corbet wrote: > On Sun, 11 Dec 2016 18:35:42 +0100 > Daniel Vetter wrote: > >> > Here's a thought, though: how about if we slip in a little version of >> > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the >> > rest

[PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time

From: Laurent Pinchart The drm driver .load() operation is prone to race conditions as it initializes the driver after registering the device nodes. Its usage is deprecated, inline it in the probe function and call drm_dev_alloc() and drm_dev_register()

[RFC] Using DC in amdgpu for upcoming GPU

On Tue, Dec 13, 2016 at 12:22:59PM +, Daniel Stone wrote: > Hi Harry, > I've been loathe to jump in here, not least because both cop roles > seem to be taken, but ... > > On 13 December 2016 at 01:49, Harry Wentland > wrote: > > On 2016-12-11 09:57 PM, Dave Airlie wrote: > >> On 8 December

[PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.

Hi, On 12/12/2016 4:04 PM, Maarten Lankhorst wrote: > Do something similar to vc4, only allow updating the cursor state > in-place through a fastpath when the watermarks are unaffected. This > will allow cursor movement to be smooth, but changing cursor size or > showing/hiding cursor will still

[PATCH libdrm] autogen.sh: set format.subjectPrefix and sendemail.to if needed

Just set the rules automatically rather than asking each contributor to update thing locally. Signed-off-by: Emil Velikov --- autogen.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/autogen.sh b/autogen.sh index c896097..e936f04 100755 --- a/autogen.sh +++ b/autogen.sh @@ -9,6

[PATCH v3 10/20] drm: omapdrm: Only commit planes on active CRTCs

Hi Tomi, On Tuesday 13 Dec 2016 09:58:34 Tomi Valkeinen wrote: > On 13/12/16 00:53, Laurent Pinchart wrote: > > On Tuesday 20 Sep 2016 16:51:11 Tomi Valkeinen wrote: > >> On 19/09/16 15:27, Laurent Pinchart wrote: > >>> The DRM core supports skipping plane update for inactive CRTCs for > >>>

[PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.

Op 13-12-16 om 14:01 schreef Archit Taneja: > Hi, > > On 12/12/2016 4:04 PM, Maarten Lankhorst wrote: >> Do something similar to vc4, only allow updating the cursor state >> in-place through a fastpath when the watermarks are unaffected. This >> will allow cursor movement to be smooth, but

[Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.

Op 09-12-16 om 09:25 schreef Daniel Vetter: > On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote: >> Hi Daniel, >> >> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote: >>> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote: Atomic drivers may set properties

[PATCH libdrm] autogen.sh: set format.subjectPrefix and sendemail.to if needed

On Tue, 13 Dec 2016, Emil Velikov wrote: > Just set the rules automatically rather than asking each contributor to > update thing locally. > > Signed-off-by: Emil Velikov > --- > autogen.sh | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/autogen.sh b/autogen.sh > index

[PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug

On Thu, 08 Dec 2016, Manasi Navare wrote: > Daniel, can we merge this patch? Pushed this one to dinq, thanks for the patch. BR, Jani. > It has no dependency on other link train patches, > it is just a clean up for the existing driver code that > uses max link rate and lane count values. >

[PATCH v7 3/4] drm/i915: Find fallback link rate/lane count

On Fri, 09 Dec 2016, Jani Nikula wrote: > On Fri, 09 Dec 2016, Manasi Navare wrote: >> If link training fails, then we need to fallback to lower >> link rate first and if link training fails at RBR, then >> fallback to lower lane count. >> This function finds the next lower link rate/lane count

[Intel-gfx] [PATCH] drm: Fix for invalid pruning of modes in dual display cases

On Tue, 13 Dec 2016, Chris Wilson wrote: > On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote: >> Currently in dual display connected boot scenarios, minimum of the >> resolutions >> is taken for fb width and height as reference. Based on this resolution, >> other >> modes are

[RFC] Using DC in amdgpu for upcoming GPU

On Mon, Dec 12, 2016 at 11:10 PM, Cheng, Tony wrote: > We need to treat most of resource that don't map well as global. One example > is pixel pll. We have 6 display pipes but only 2 or 3 plls in CI/VI, as a > result we are limited in number of HDMI or DVI we can drive at the same > time. Also

[PATCH 04/34] drm: Add some kselftests for the DRM range manager (struct drm_mm)

On ti, 2016-12-13 at 10:21 +, Chris Wilson wrote: > On Tue, Dec 13, 2016 at 11:58:54AM +0200, Joonas Lahtinen wrote: > > > > This could be build time, depending on the intended use. > > I was thinking module param for the seed, just in case we want different > patterns. As discussed in IRC,

[RFC] Using DC in amdgpu for upcoming GPU

t; our own version of clean up patch community want to see? > Thanks, > > Lukas -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/45d229b9/attachment-0001.html>

[PATCH 24/34] drm: Compile time enabling for asserts in drm_mm

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and > validation checking using BUG_ON. Ideally these paths should all be > exercised by CI selftests (with the asserts enabled). > > Signed-off-by: Chris Wilson Reviewed-by:

[PATCH] drm: tilcdc: simplify the recovery from sync lost error on rev1

Revision 2 of LCDC suffers from an issue where a SYNC_LOST error caused by limited memory bandwidth may leave the picture shifted a couple pixels to the right. This issue has not been observed on revision 1, while the recovery mechanism introduces a different issue, where the END_OF_FRAME

[PATCH 1/4] video: add HDMI state notifier support

From: Hans Verkuil Add support for HDMI hotplug and EDID notifiers, which is used to convey information from HDMI drivers to their CEC and audio counterparts. Based on an earlier version from Russell King: https://patchwork.kernel.org/patch/9277043/ The hdmi_notifier

[PATCH 4/4] s5p-cec: add hdmi-notifier support, move out of staging

From: Hans Verkuil By using the HDMI 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 documenting the

[PATCH 2/4] exynos_hdmi: add HDMI notifier support

From: Hans Verkuil Implement the HDMI 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: Hans Verkuil --- drivers/gpu/drm/exynos/Kconfig | 1 +

[PATCH 3/4] cec: integrate HDMI notifier support

From: Hans Verkuil Support the HDMI notifier framework, simplifying drivers that depend on this. Signed-off-by: Hans Verkuil --- drivers/media/cec/cec-core.c | 50 include/media/cec.h | 15 + 2 files

[PATCH 0/4] video/exynos/cec: add HDMI state notifier & use in s5p-cec

From: Hans Verkuil This patch series adds the HDMI notifier code, based on Russell's code: https://patchwork.kernel.org/patch/9277043/ It adds support for it to the exynos_hdmi drm driver, adds support for it to the CEC framework and finally adds support to the s5p-cec

[RFC] Using DC in amdgpu for upcoming GPU

all changes and "rewrite" our own version of clean up patch community want to see? Thanks, Lukas -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161213/9cb9eae2/attachment.html>

[PATCH 06/34] drm: Add a simple linear congruent generator PRNG

Hey Chris On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson wrote: > For testing, we want a reproducible PRNG, a plain linear congruent > generator is suitable for our very limited selftests. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/Kconfig| 5 + >

[RFC PATCH 0/3] staging: remove fbdev drivers

Hi Daniel, On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > > > Hi, > > > > > > Since the fbdev framework is in maintenance mode and all new display > > >

[PATCH 25/34] drm: Extract struct drm_mm_scan from struct drm_mm

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > The scan state occupies a large proportion of the struct drm_mm and is > rarely used and only contains temporary state. That makes it suitable to > moving to its struct and onto the stack of the callers. > > Signed-off-by: Chris Wilson >

[PATCH 06/34] drm: Add a simple linear congruent generator PRNG

On Tue, Dec 13, 2016 at 4:16 PM, David Herrmann wrote: > On Mon, Dec 12, 2016 at 12:53 PM, Chris Wilson > wrote: > for (i = 0; i < count; ++i) > swap(order[i], order[drm_lcg_random(state) % count]); > > Much simpler and I cannot see why it wouldn't work. Hint: swap() does multiple

[PATCH 1/4] drm: Protect master->unique with dev->master_mutex

On 13 December 2016 at 09:46, Daniel Vetter wrote: > On Tue, Dec 13, 2016 at 10:42 AM, Michel Dänzer > wrote: >>> Hm, I thought the grand plan is to use -modesetting almost everywhere and >>> forget about all the others? >> >> Maybe if you mean s/grand plan/pipe dream/ ... > > I said "almost

[PATCH 0/2] omapdrm: Remove .load/.unload midlayer

Hello, This small patch series removes the .load and .unload operations from the omapdrm driver and moves the code to the probe/remove handlers. The patches are based on top of my pending omapdrm stack, and have been pushed for convenience to git://linuxtv.org/pinchartl/media.git

[PATCH 1/2] drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structures

By linking the sizeof to a variable type the code will be less prone to bugs due to future type changes of variables. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 2 +- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 3 +--

[PATCH 2/2] drm: omapdrm: Perform initialization/cleanup at probe/remove time

The drm driver .load() operation is prone to race conditions as it initializes the driver after registering the device nodes. Its usage is deprecated, inline it in the probe function and call drm_dev_alloc() and drm_dev_register() explicitly. For consistency inline the .unload() handler in the

[PATCH 26/34] drm: Rename prev_node to hole in drm_mm_scan_add_block()

On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Acknowledging that we were building up the hole was more useful to me > when reading the code, than knowing the relationship between this node > and the previous node. > I don't really agree. I see that we have nodes and there are holes

  1   2   >