[PATCH 6/7] drm/rcar: gem: dumb: pitch is an output

On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote: > (On a side note I believe treating the pitch and size arguments as inputs > could be a worthwhile extension to the API, but given that we haven't > rejected incorrect values in the past we're pretty much stuck). The bigger

[Bug 82918] [tahiti xt] dota2 crashes

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/17a37f8b/attachment.html>

[Bug 84021] [game][the cave] not rendered properly

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141106/0bc077c0/attachment.html>

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 --- Comment #4 from Michel Dänzer --- (In reply to aCaB from comment #3) > I understand mesa may be sending crap to the kernel space but that doesn't > sound like a good reason to deref a NULL. AFAICT that should be fixed by the changes to

exynos-drm registration: infinite loop

Hi, On 2014년 11월 05일 02:18, Matwey V. Kornilov wrote: > Hi, > > I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM > of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is > set to 'y'. > The issue here is that the platform probe/init goes to infinite

[Bug 79980] Random radeonsi crashes

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/bbda3936/attachment.html>

[Bug 85950] GLAMOR crashes w/ radeon rv6xx GPU when using OpenGL games

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9b380d7c/attachment.html>

[Bug 85950] GLAMOR crashes w/ radeon rv6xx GPU when using OpenGL games

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141106/6fdebcaf/attachment-0001.html>

exynos-drm registration: infinite loop

On 2014년 11월 05일 23:38, Thierry Reding wrote: > On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: >> Hi, >> >> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM >> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is >> set to 'y'. >>

[PATCH] drm/panel: ld9040: Update calls to gpiod_get*()

On 11/06/2014 04:32 AM, Alexandre Courbot wrote: > On Thu, Oct 23, 2014 at 6:45 PM, Andrzej Hajda wrote: >> On 10/23/2014 10:16 AM, Alexandre Courbot wrote: >>> Add the new flags argument to calls of (devm_)gpiod_get*() and >>> remove any direction setting code afterwards. >>> >>> Currently both

exynos-drm registration: infinite loop

On 11/06/2014 07:23 AM, Inki Dae wrote: > On 2014년 11월 05일 23:38, Thierry Reding wrote: >> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: >>> Hi, >>> >>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM >>> of course, but I run multi-platform kernel

exynos-drm registration: infinite loop

On 2014년 11월 06일 17:03, Andrzej Hajda wrote: > On 11/06/2014 07:23 AM, Inki Dae wrote: >> On 2014년 11월 05일 23:38, Thierry Reding wrote: >>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: Hi, I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have

[PATCH] drm/panel: ld9040: Update calls to gpiod_get*()

d, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/8bb179e5/attachment-0001.sig>

[PATCH] drm/panel: s6e8aa0: Update calls to gpiod_get*()

d, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3d0d3d1b/attachment.sig>

[PATCH] drm/panel: simple: Update calls to gpiod_get*()

deletions(-) Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9d0662d2/attachment.sig>

[PATCH v2 1/2] of: Add vendor prefix for HannStar Display Corporation

pplication/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/91983c87/attachment.sig>

[PATCH v2 2/2] drm/panel: Add HannStar HSD070PWW1 7.0" WXGA TFT LCD panel

> create mode 100644 > Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <

exynos-drm registration: infinite loop

On 2014년 11월 06일 17:49, Matwey V. Kornilov wrote: > 2014-11-06 11:45 GMT+03:00 Inki Dae : >> On 2014년 11월 06일 17:03, Andrzej Hajda wrote: >>> On 11/06/2014 07:23 AM, Inki Dae wrote: On 2014년 11월 05일 23:38, Thierry Reding wrote: > On Tue, Nov 04, 2014 at 09:18:46PM +0400,

[BUG] blocked task after exynos_drm_init

Hi, On last next (next-20141104, next-20141105) booting locks after initializing Exynos DRM (Trats2 board): [2.028283] [drm] Initialized drm 1.1.0 20060810 [ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds. [ 240.510825] Not tainted 3.18.0-rc3-next-20141105 #794

[PATCH] drm/panel: simple: Add AUO B116XW03 panel support

p://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b68612f2/attachment.sig>

[PATCH] drm/panel: simple: Add missing .bpc fields

From: Thierry Reding Various panels were missing the .bpc field which encodes the number of bits per color. Not every display driver relies on this value, but since the panels can be used with any display engine it must be specified so that if a driver knows how to

exynos-drm registration: infinite loop

because this currently causes all sorts of weirdness when booting a multi-platform kernel on non-Exynos boards. Probably the easiest for now would be to add some soc_is_exynos*() check at the very beginning of exynos_drm_init(). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/98dcd330/attachment.sig>

[Intel-gfx] 3.18.0-rc3: i915: eDP connected Display stays blank

On Thu, 06 Nov 2014, Arnd Hannemann wrote: > Hi, > > I have a Thinkpad T440s (Haswell) connected to two additional Monitors > via a Docking Station (MST). > > During Bootup all three displays work, even when X is started. > However, if the laptop display is turned off once (either because of >

[RFC] dpms handling on atomic drivers

Hi all, After a few atomic irc chats I've shockingly realized that I've completely ignored dpms handling in my helper series. Oops. But there's a few things which are seriously wrong with DPMS, so I've figured I'll start a discussion about them first - converting to atomic looks like a good time

[RFC 1/2] core: Add generic object registry implementation

nt as well. But instead of passing around void * and type IDs as in the interface tracker it could deal with real objects for proper type- safety. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/44968ab0/attachment-0001.sig>

exynos-drm registration: infinite loop

On 2014년 11월 06일 18:29, Thierry Reding wrote: > On Thu, Nov 06, 2014 at 03:23:27PM +0900, Inki Dae wrote: >> On 2014년 11월 05일 23:38, Thierry Reding wrote: >>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: Hi, I run 3.18-rc3 kernel on BeagleBone

[PATCH 0/2] make imx hdmi publicly used by dw hdmi compatible platform

On Thu, Nov 06, 2014 at 05:35:40PM +0800, Kuankuan.Yang wrote: > I'm working on Designware hdmi-audio, also add it as a standard ALSA device. > Before I saw this email, I also planed to submit my patchs to upsteam. > I'm very grateful if you can email those patchs to us. I've attached the set of

[RFC 1/2] core: Add generic object registry implementation

ifferently if at all possible. try_module_get() is the only way I know of that ensures that the code of a module stays around. Everytime we give out a new reference to a record we also need to increment the module reference count accordingly to make sure the underlying code doesn't go away all of a sudden. I guess that's not entirely accurate. The module reference count doesn't have to be increment for every record reference, it only needs to track each record. So the try_module_get() and module_put() could move into registry_add() and registry_get(), respectively. But the ->owner field would still be in the record structure. Would that alleviate your concerns? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/1b589fb1/attachment.sig>

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform

This patch resolves temporarily infinite loop issue incurred when Exynos drm driver is enabled and multi-platform kernel is used by registering Exynos drm device object only in case of Exynos SoC. So this patch will be replaced with more generic way later. Signed-off-by: Inki Dae ---

[PATCH] drm/exynos/dsi: simplify hotplug code

Exynos DSI driver uses DSI bus attach/detach callbacks to implement panel hotplug mechanism. The patch moves panel attachment code from .detect callback to DSI bus callbacks. It makes the code simpler and more straightforward. The patch removes also redundant and lock unprotected dpms_off call

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform

On 06.11.2014 11:32, Inki Dae wrote: > This patch resolves temporarily infinite loop issue incurred > when Exynos drm driver is enabled and multi-platform kernel > is used by registering Exynos drm device object only in case > of Exynos SoC. So this patch will be replaced with more generic > way

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform

On 2014년 11월 06일 21:11, Krzysztof Kozłowski wrote: > On 06.11.2014 11:32, Inki Dae wrote: >> This patch resolves temporarily infinite loop issue incurred >> when Exynos drm driver is enabled and multi-platform kernel >> is used by registering Exynos drm device object only in case >> of

[PATCH 1/9] drm/exynos: remove uneeded declaration of struct dma_iommu_mapping

Hi Inki, Could you please give a review to this series? Thanks. Gustavo 2014-10-31 Gustavo Padovan : > From: Gustavo Padovan > > It is not even used in this header anymore. > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 - > 1 file

[PATCH 1/9] drm/exynos: remove uneeded declaration of struct dma_iommu_mapping

Hi Gustavo, On 2014년 11월 06일 21:38, Gustavo Padovan wrote: > > Hi Inki, > > Could you please give a review to this series? It looks good to me. This patch series is just cleanup but not test so I will merge them next week after testing if there is no any comment. Thanks, Inki Dae > >

[Intel-gfx] 3.18.0-rc3: i915: eDP connected Display stays blank

On Thu, 06 Nov 2014, Arnd Hannemann wrote: > Hi, > > thanks for your quick response. > > Am 06.11.2014 um 10:39 schrieb Jani Nikula: >> On Thu, 06 Nov 2014, Arnd Hannemann wrote: >>> Hi, >>> >>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors >>> via a Docking Station

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform

On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote: > On 2014년 11월 06일 21:11, Krzysztof Kozłowski wrote: > > On 06.11.2014 11:32, Inki Dae wrote: > >> This patch resolves temporarily infinite loop issue incurred > >> when Exynos drm driver is enabled and multi-platform kernel > >> is used by

[PATCH] drm/exynos/dsi: simplify hotplug code

a DSI bus. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/09098297/attachment.sig>

[PATCH] drm/exynos/dsi: simplify hotplug code

On 11/06/2014 02:18 PM, Thierry Reding wrote: > On Thu, Nov 06, 2014 at 12:35:48PM +0100, Andrzej Hajda wrote: >> Exynos DSI driver uses DSI bus attach/detach callbacks to implement >> panel hotplug mechanism. The patch moves panel attachment code >> from .detect callback to DSI bus callbacks. It

[PATCH] drm/exynos: resolve infinite loop issue on multi-platform

On 2014년 11월 06일 22:00, Krzysztof Kozlowski wrote: > On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote: >> On 2014년 11월 06일 21:11, Krzysztof Kozłowski wrote: >>> On 06.11.2014 11:32, Inki Dae wrote: This patch resolves temporarily infinite loop issue incurred when Exynos drm

[PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

This patch resovles the infinite loop issue incurred when Exyno drm driver is enabled but all kms drivers are disabled on Exynos board by returning -EPROBE_DEFER only in case that there is kms device registered. Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++

[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b1634317/attachment.html>

[Bug 80365] [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/5dcde002/attachment.html>

[PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

Hi Inki, With all respect, On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite loop issue incurred > when Exyno drm driver is enabled but all kms drivers > are disabled on Exynos board by returning -EPROBE_DEFER > only in case that there is kms device registered. > I believe

[PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

On 06/11/14 15:44, Emil Velikov wrote: > Hi Inki, > > With all respect, > > On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite > loop issue incurred >> when Exyno drm driver is enabled but all kms drivers >> are disabled on Exynos board by returning -EPROBE_DEFER >> only in

[PATCH v2 0/8] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

From: Thierry Reding This second version addresses review comments from before. A new patch is added that removes a redundant call to drm_gem_free_mmap_offset() in the CMA GEM helpers. Below is the cover letter from the first version for more background in case anybody

[PATCH v2 1/8] drm/gem: Fix a few kerneldoc typos

From: Thierry Reding While at it, adjust the drm_gem_handle_create() function declaration to be more consistent with other functions in the file. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_gem.c | 11 +-- 1 file changed, 5

[PATCH v2 2/8] drm/doc: mm: Fix indentation

From: Thierry Reding Use spaces consistently for indentation in the memory-management section. Acked-by: Daniel Vetter Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 268 - 1 file changed, 134 insertions(+), 134

[PATCH v2 3/8] drm/doc: Add GEM/CMA helpers to kerneldoc

From: Thierry Reding Most of the functions already have the beginnings of kerneldoc comments but are using the wrong opening marker. Use the correct opening marker and flesh out the comments so that they can be integrated with the DRM DocBook document. Signed-off-by: Thierry

[PATCH v2 4/8] drm/cma: Introduce drm_gem_cma_dumb_create_internal()

From: Thierry Reding This function is similar to drm_gem_cma_dumb_create() but targetted at kernel internal users so that they can override the pitch and size requirements of the dumb buffer. It is important to make this difference because the IOCTL says that the pitch and

[PATCH v2 5/8] drm/omap: gem: dumb: pitch is an output

From: Thierry Reding When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB IOCTL, only the width, height, bpp and flags fields are inputs. The caller is not guaranteed to zero out or set handle, pitch and size. Drivers must not treat these values as possible

[PATCH v2 6/8] drm/rcar: gem: dumb: pitch is an output

From: Thierry Reding When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB IOCTL, only the width, height, bpp and flags fields are inputs. The caller is not guaranteed to zero out or set handle, pitch and size. Drivers must not treat these values as possible

[PATCH v2 7/8] drm: Sanitize DRM_IOCTL_MODE_CREATE_DUMB input

From: Thierry Reding Some drivers treat the pitch and size fields as inputs and will use them as minima provided by userspace so that they are only overwritten if the minimal requirements of the driver exceed them. This can cause strange behaviour when applications don't

[PATCH v2 8/8] drm/cma: Remove call to drm_gem_free_mmap_offset()

From: Thierry Reding drm_gem_object_release() called later in the drm_gem_cma_free_object() function already calls this, so there's no need to do this explicitly. Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_gem_cma_helper.c | 2 -- 1 file changed, 2 deletions(-)

[PATCH V3 4/4] dw-hdmi: convert dw-hdmi to drm_bridge mode

On Thu, Nov 06, 2014 at 07:26:16PM +0800, Andy Yan wrote: > From: ykk We need a "real" name here, sorry. > > dw-hdmi is under drm/bridge, so it should be the bridge mode. > hange off the encoder to dw_hdmi-imx.c, keep the connector & > birdge in dw_hdmi.c > > Signed-off-by: ykk Same here.

[PATCH 1/3] drm/tegra: Fix error handling cleanup

From: Thierry Reding The DRM driver's ->load() implementation didn't do a good job (no job at all really) cleaning up on failure. Fix that by undoing any prior setup when an error occurs. This requires a bit of rework to make it possible to clean up fbdev midway. This was

[PATCH v6 2/3] drm/tegra: Add IOMMU support

From: Thierry Reding When an IOMMU device is available on the platform bus, allocate an IOMMU domain and attach the display controllers to it. The display controllers can then scan out non-contiguous buffers by mapping them through the IOMMU. Signed-off-by: Thierry Reding

[PATCH 3/3] drm/tegra: gem: Check before freeing CMA memory

From: Thierry Reding dma_free_writecombine() must not be called on a buffer that couldn't be allocated. Check for a valid virtual address before attempting to free the memory to avoid a crash. Reported-by: Sean Paul Signed-off-by: Thierry Reding ---

-next plans/status

on-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fcf157e9/attachment.sig>

[RFC 1/2] core: Add generic object registry implementation

le URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/f280695e/attachment-0001.sig>

[PATCH weston 1/1] compositor: Abort on bad page flip timestamps

On Thu, 06 Nov 2014 16:08:56 +0900 Michel Dänzer wrote: > On 06.11.2014 03:06, Frederic Plourde wrote: > > Many features, like animations, hardly depend on page flip timestamps > > to work properly, but some DRM drivers do not correctly support page flip > > timestamps (or not at all) and in

[PATCH 2/3] of: Add vendor prefix for Hitachi Ltd. Corporation

Signed-off-by: Lucas Stach --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d73744..fed0c8d60748 100644 ---

[PATCH 1/3] drm/panel: add support for Innolux G121I1-L01 12.1" TFT LCD panel

This patch adds support for the Innolux G121I1-L01 12.1" TFT LCD panel to the simple-panel driver. This panel is connected via LVDS and uses the data enable signal for timing. Since HSYNC/VSYNC are ignored, the split between sync length and porches is arbitrary, as long as the complete horizontal

[PATCH 3/3] drm/panel: add Hitachi TX23D38VM0CAA 9" WVGA TFT LCD panel

This patch adds support for the Hitachi TX23D38VM0CAA 9" WVGA TFT LCD panel to the simple-panel driver. This panel is connected via LVDS and uses the data enable signal for timing. Since HSYNC/VSYNC are ignored, the split between sync length and porches is arbitrary, as long as the complete

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3930670e/attachment.html>

[Intel-gfx] [PATCH 13/17] drm/atomic-helpers: document how to implement async commit

On Sun, Nov 02, 2014 at 02:19:26PM +0100, Daniel Vetter wrote: > No helper function to do it all yet provided since no driver has > support for driver core fences yet. Which we'd need to make the > implementation really generic. > > v2: Clarify async howto a bit per the discussion With Rob Clark.

[PATCH 14/17] drm/atomic-helper: implement ->page_flip

On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote: > Currently there is no way to implement async flips using atomic, that > essentially requires us to be able to cancel pending requests > mid-flight. > > To be able to do that (and I guess we want this since vblank synced > updates

[Intel-gfx] [PATCH 15/17] drm/atomic-helpers: functions for state duplicate/destroy/reset

On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote: > The atomic users and helpers assume that there is always a obj->state > structure around. Which means drivers need to somehow create that at > driver load time. Also it should obviously reset hardware state, so > needs to be reset

[PATCH 16/17] drm: Docbook integration and over sections for all the new helpers

On Sun, Nov 02, 2014 at 02:19:29PM +0100, Daniel Vetter wrote: > In all cases the text requires that new drivers are converted to the > atomic interfaces. > > v2: Add overview for state handling. > > Signed-off-by: Daniel Vetter > --- > Documentation/DocBook/drm.tmpl | 20

[PATCH 17/17] drm/atomic: Refcounting for plane_state->fb

On Sun, Nov 02, 2014 at 02:19:30PM +0100, Daniel Vetter wrote: > So my original plan was that the drm core refcounts framebuffers like > with the legacy ioctls. But that doesn't work for a bunch of reasons: > > - State objects might live longer than until the next fb change > happens for a

[PATCH 14/17] drm/atomic-helper: implement ->page_flip

On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote: > On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote: > > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc); > > +retry: > > + crtc_state = drm_atomic_get_crtc_state(state, crtc); > > + if (IS_ERR(crtc_state)) { > > +

[PATCH 6/7] drm/rcar: gem: dumb: pitch is an output

Hi Russell, On Thursday 06 November 2014 00:54:51 Russell King - ARM Linux wrote: > On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote: > > (On a side note I believe treating the pitch and size arguments as inputs > > could be a worthwhile extension to the API, but given that we

[PATCH 10/17] drm: Atomic crtc/connector updates using crtc/plane helper interfaces

On Wed, Nov 5, 2014 at 4:44 PM, Daniel Vetter wrote: > I've applied all the other nits, replies to the more interesting bits > below. > > On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote: >> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote: >> > + if (new_encoder !=

[PATCH] drm/atomic-helper: implementatations for legacy interfaces

On Wed, Nov 5, 2014 at 5:01 PM, Daniel Vetter wrote: > On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote: >> > + if (!crtc && crtc != set->crtc) >> >> I think this should be an || > > Hm. My idea idea was actually something along the lines of > diff --git

[Intel-gfx] [PATCH 14/17] drm/atomic-helper: implement ->page_flip

On Thu, Nov 6, 2014 at 1:13 PM, Daniel Vetter wrote: > > On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote: > > On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote: > > > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc); > > > +retry: > > > + crtc_state =

[PATCH 1/3] drm/tegra: Fix error handling cleanup

On Thu, Nov 06, 2014 at 04:57:14PM +0100, Thierry Reding wrote: > From: Thierry Reding > > The DRM driver's ->load() implementation didn't do a good job (no job at > all really) cleaning up on failure. Fix that by undoing any prior setup > when an error occurs. This requires a bit of rework to

[PATCH 3/3] drm/tegra: gem: Check before freeing CMA memory

On Thu, Nov 6, 2014 at 10:57 AM, Thierry Reding wrote: > From: Thierry Reding > > dma_free_writecombine() must not be called on a buffer that couldn't be > allocated. Check for a valid virtual address before attempting to free > the memory to avoid a crash. > > Reported-by: Sean Paul nit: I'd

[PATCH] drm/atomic-helpers: functions for state duplicate/destroy/reset

The atomic users and helpers assume that there is always a obj->state structure around. Which means drivers need to somehow create that at driver load time. Also it should obviously reset hardware state, so needs to be reset upon resume. Finally the destroy/duplicate_state functions are an awful

[Intel-gfx] [PATCH 15/17] drm/atomic-helpers: functions for state duplicate/destroy/reset

On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote: > On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote: > > The atomic users and helpers assume that there is always a obj->state > > structure around. Which means drivers need to somehow create that at > > driver load time. Also

[PATCH] drm: Docbook integration and over sections for all the new helpers

In all cases the text requires that new drivers are converted to the atomic interfaces. v2: Add overview for state handling. v3: Review from Sean: Some spelling fixes and drop the misguided hunk to remove rgba from the plane helpers compat list. Cc: Sean Paul Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 15/17] drm/atomic-helpers: functions for state duplicate/destroy/reset

On Thu, Nov 6, 2014 at 2:57 PM, Daniel Vetter wrote: > On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote: >> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote: >> > The atomic users and helpers assume that there is always a obj->state >> > structure around. Which means drivers

[PATCH] drm: Docbook integration and over sections for all the new helpers

On Thu, Nov 6, 2014 at 3:00 PM, Daniel Vetter wrote: > In all cases the text requires that new drivers are converted to the > atomic interfaces. > > v2: Add overview for state handling. > > v3: Review from Sean: Some spelling fixes and drop the misguided > hunk to remove rgba from the plane

[PATCH v2 3/8] drm/doc: Add GEM/CMA helpers to kerneldoc

On Thu, Nov 06, 2014 at 04:49:16PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Most of the functions already have the beginnings of kerneldoc comments > but are using the wrong opening marker. Use the correct opening marker > and flesh out the comments so that they can be integrated

[PATCH v2 8/8] drm/cma: Remove call to drm_gem_free_mmap_offset()

On Thu, Nov 06, 2014 at 04:49:21PM +0100, Thierry Reding wrote: > From: Thierry Reding > > drm_gem_object_release() called later in the drm_gem_cma_free_object() > function already calls this, so there's no need to do this explicitly. > > Signed-off-by: Thierry Reding Reviewed-by: Daniel

[PATCH 0/3] drm/msm: Adreno 4xx support

On Fri, Oct 31, 2014 at 11:07 AM, Ganesan, Aravind wrote: > Resend the patch-set with the same thread-id > A set of three patches to support adreno 4xx GPUs in msm-drm: > (1) Updated the a3xx and a4xx header files. > (2) Handle register offset differences between a3xx and a4xx GPUs. > (3) Added

[PATCH 2/3] drm/msm: Handle register offset differences between a3xx, and a4xx

On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind wrote: > Register offsets have changed between a3xx and a4xx GPUs. > To be able access these registers in common code, we create > a lookup table, and set of read-write APIs to access the > register through the lookup table. > > Signed-off-by:

[PATCH 3/3] drm/msm: a4xx support for msm-drm

On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind wrote: > Added a4xx GPU support. > > Signed-off-by: Aravind Ganesan > --- > Resend the patch-set with the same thread-id > Resend in patch-set format and with dri-devel at lists.freedesktop.org on > the CC. > drivers/gpu/drm/msm/Makefile

[Bug 87791] radeonsi lockup and oops

https://bugzilla.kernel.org/show_bug.cgi?id=87791 --- Comment #5 from aCaB --- Michel, Thanks for your pointer and sorry for the late answer. I'll try harder to find a reproducible case (firefox with some large animation seems to trigger it some times). In the meantime, if the lockup is a mesa

[Bug 85866] Desktop environment becomes unresponsive, but mouse can move after distro update

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9ff4143d/attachment.html>

[Bug 85866] Desktop environment becomes unresponsive, but mouse can move after distro update

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3d1aa9a1/attachment.html>

[RFC] dpms handling on atomic drivers

On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote: > Hi all, > > After a few atomic irc chats I've shockingly realized that I've completely > ignored dpms handling in my helper series. Oops. > > But there's a few things which are seriously wrong with DPMS, so I've > figured I'll start a

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/8d69d5a4/attachment.html>

[PATCH v2 5/8] drm/omap: gem: dumb: pitch is an output

On Thu, Nov 6, 2014 at 10:49 AM, Thierry Reding wrote: > From: Thierry Reding > > When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB > IOCTL, only the width, height, bpp and flags fields are inputs. The > caller is not guaranteed to zero out or set handle, pitch and size. >

[RFC] dpms handling on atomic drivers

On Thu, Nov 6, 2014 at 5:06 PM, Rob Clark wrote: > On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote: >> Hi all, >> >> After a few atomic irc chats I've shockingly realized that I've completely >> ignored dpms handling in my helper series. Oops. >> >> But there's a few things which are

[pull] radeon drm-fixes-3.18

Hi Dave, A few more radeon fixes for 3.18: - fix missing crtc unlock in MC setup - set optimal CE ram config - use gart rather than vram for DMA IB tests to avoid coherency issues with HDP - fix a crasher with laptop mode and TDP scripts The following changes since commit

[Bug 85866] Desktop environment becomes unresponsive, but mouse can move after distro update

assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fc607b22/attachment.html>

[RFC] dpms handling on atomic drivers

On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter wrote: > > Hi all, > > After a few atomic irc chats I've shockingly realized that I've completely > ignored dpms handling in my helper series. Oops. > > But there's a few things which are seriously wrong with DPMS, so I've > figured I'll start a

[RFC] dpms handling on atomic drivers

On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote: >>> Proposal. Add a new boolean ->active to the crtc state, which will track >>> the dpms state of the crtc. Add a helper to the atomic core functions >>> which will compute ->active from the state update according to the >>> proposals for

[PATCH] drm/panel: s6e8aa0: Update calls to gpiod_get*()

On Thu, Oct 23, 2014 at 6:46 PM, Andrzej Hajda wrote: > On 10/23/2014 10:16 AM, Alexandre Courbot wrote: >> Add the new flags argument to calls of (devm_)gpiod_get*() and >> remove any direction setting code afterwards. >> >> Currently both forms (with or without the flags argument) >> are valid

exynos-drm registration: infinite loop

2014-11-06 11:45 GMT+03:00 Inki Dae : > On 2014년 11월 06일 17:03, Andrzej Hajda wrote: >> On 11/06/2014 07:23 AM, Inki Dae wrote: >>> On 2014년 11월 05일 23:38, Thierry Reding wrote: On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote: > Hi, > > I run

[Intel-gfx] 3.18.0-rc3: i915: eDP connected Display stays blank

Hi, thanks for your quick response. Am 06.11.2014 um 10:39 schrieb Jani Nikula: > On Thu, 06 Nov 2014, Arnd Hannemann wrote: >> Hi, >> >> I have a Thinkpad T440s (Haswell) connected to two additional Monitors >> via a Docking Station (MST). >> >> During Bootup all three displays work, even when

  1   2   >