[PATCH] imx-drm: imx-drm-core: add suspend/resume support

On Thu, Jul 24, 2014 at 12:38:59PM +0200, Daniel Vetter wrote: > > > > +static int imx_drm_suspend(struct device *dev) > > > > +{ > > > > + struct drm_device *drm_dev = dev_get_drvdata(dev); > > > > + struct drm_connector *connector; > > > > + > > > > +

[PATCH] gpu: drm: omapdrm: Use %pad format for values of the dma_addr_t type

From: "Matwey V. Kornilov" The format change is to fix the following compilation issue: ../drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply': ../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but

[PATCH v2 00/25] AMDKFD kernel driver

On 24/07/14 21:47, Jerome Glisse wrote: > On Thu, Jul 24, 2014 at 01:35:53PM -0400, Alex Deucher wrote: >> On Thu, Jul 24, 2014 at 11:44 AM, Jerome Glisse >> wrote: >>> On Thu, Jul 24, 2014 at 01:01:41AM +0300, Oded Gabbay wrote: On 24/07/14 00:46, Bridgman, John wrote: > >>

[PATCH 2/2] drm/radeon: add new info ioctl query for hawaii accel

We need to make sure we have a new enough firmware with the fixed nop packet. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_kms.c | 6 ++ include/uapi/drm/radeon_drm.h | 1 + 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c

[PATCH 1/2] drm/radeon: fix cut and paste issue for hawaii.

From: Jerome Glisse This is a halfway fix for hawaii acceleration. More fixes to come but hopefully isolated to userspace. Signed-off-by: J?r?me Glisse Cc: stable at vger.kernel.org Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/cik.c | 1 + 1 file changed, 1

[PATCH] [rfc] drm: close race in connector registration

> > This is the same we do for minor-objects, so fine with me. I'd prefer > if the registration is done last in drm_connector_register(), not > first, but I'm not sure the debugfs hooks work without the connector > available in the lookup tables. Maybe worth a try. I was worried sysfs

[Bug 81683] [r600g] graphic glitches in Skyrim - failed to build shader

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140724/61f12cff/attachment.html>

[Bug 81683] [r600g] graphic glitches in Skyrim - failed to build shader

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140724/378e754b/attachment.html>

[PATCH] gpio: extend gpiod_get*() with flags parameter

Hi Alexandre, Thank you for the patch. On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote: > The huge majority of GPIOs have their direction and initial value set > right after being obtained by one of the gpiod_get() functions. The > integer GPIO API had gpio_request_one() that took a

[PATCH] gpio: extend gpiod_get*() with flags parameter

On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote: > I'm not sure how this could be applied harmlessly though - maybe through > a dedicated branch for -next? Problem is that a lot of new code is not > yet merged into mainline, and conflicts are very likely to occur. Linus, > do you have any

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

HDMI currently stops working after a system suspend/resume cycle. It turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get called from anywhere across suspend/resume cycle. The patch follows what exynos drm driver does to walk the list of connectors and call their .dpms

[PATCH] drm/radeon: fix cut and paste issue for hawaii.

From: Jerome Glisse This is a halfway fix for hawaii acceleration. More fixes to come but hopefully isolated to userspace. Signed-off-by: J?r?me Glisse Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/cik.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 1/1] Revert "drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters"

mparison, the workloads have to be similar for both the > powertop ratings. Attached are the two powertop runs with 'powertop --html'. Both are taken on a fresh reboot on the same kernel, just the difference is that powertop-rc6pp.html has i915.enable_rc6=7 in the cmdline. Dunno if that's what you wanted, but it shows the laptop fan is spinning with more rpm, fwiw. Both runs are taken after about 10 mins of desktop idling. > In any case, my daily work doesn't change, and I noticed this > immediately upon booting into 3.15. The laptop heats up a bit more, > that's the first clue; and the battery doesn't provide as much backup > as it used to. As I stated, I've used the deeper states on this h/w for a while w/o any adverse effects. So please consider picking this revert, or enable the deeper states for this h/w. Amit -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140724/58a513e7/attachment-0002.html> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140724/58a513e7/attachment-0003.html>

[PATCH v2 00/25] AMDKFD kernel driver

On Thu, Jul 24, 2014 at 09:57:16PM +0300, Oded Gabbay wrote: > On 24/07/14 21:47, Jerome Glisse wrote: > > On Thu, Jul 24, 2014 at 01:35:53PM -0400, Alex Deucher wrote: > >> On Thu, Jul 24, 2014 at 11:44 AM, Jerome Glisse > >> wrote: > >>> On Thu, Jul 24, 2014 at 01:01:41AM +0300, Oded Gabbay

[PATCH 0/8] tilcdc-panel: Backlight and GPIO devicetree support

On 07/11/2014 09:18 AM, Ezequiel Garcia wrote: > Hello all, > > This patchset adds the required changes to support an optional backlight > and GPIO for the tilcdc panel driver. > > There was some code to support a backlight, but it was somewhat broken > and undocumented. I've followed the nice

[RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue

On Wed, Jul 23, 2014 at 11:18 AM, Ajay kumar wrote: > On Wed, Jul 23, 2014 at 8:12 PM, Sean Paul wrote: >> On Wed, Jul 23, 2014 at 7:22 AM, Ajay kumar wrote: >>> Sean, >>> >>> On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul wrote: On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar wrote: >

[PATCH 0/7] prepare for atomic.. the great propertyification

On Thu, Jul 24, 2014 at 09:36:20AM -0400, Rob Clark wrote: > On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: > >> This is mostly just a rebase+resend. Was going to send it a bit earlier > >> but had a few things to fix up as a

[PATCH RFA 2/2] drm/i2c: tda998x: add component support

Add component helper support to the tda998x driver. This permits the TDA998x to be declared as a separate device in device tree, and bound at the appropriate moment with a co-operating card driver. The existing slave_encoder interfaces are kept while there are existing users of it in order to

[PATCH RFA 1/2] drm/i2c: tda998x: allow re-use of tda998x support code

Re-jig the TDA998x code so that we separate the functionality from the drm slave encoder implementation. In several places, this is pretty clearly the correct thing to do, because we can avoid repetitively having to convert from the drm_encoder to the TDA998x private structure, particularly with

[Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

Hi Maarten, try to implement this as a replacement for specifying the RADEON_FENCE_JIFFIES_TIMEOUT on wait_event_*. And reset the timeout every time radeon_fence_process is called and not only when any of the sequences increment. I don't have the time right now to look deeper into it or help

[PATCH] drm: Unlink dead file_priv from list of active files first

Hi On Thu, Jul 24, 2014 at 3:23 PM, Chris Wilson wrote: > In order to prevent external observers walking the list of open DRM > files from seeing an invalid drm_file_private in the process of being > torndown, the first operation we need to take is to unlink the > drm_file_private from that

[PATCH v2 00/25] AMDKFD kernel driver

On Thu, Jul 24, 2014 at 01:35:53PM -0400, Alex Deucher wrote: > On Thu, Jul 24, 2014 at 11:44 AM, Jerome Glisse wrote: > > On Thu, Jul 24, 2014 at 01:01:41AM +0300, Oded Gabbay wrote: > >> On 24/07/14 00:46, Bridgman, John wrote: > >> > > >> >> -Original Message- From: dri-devel > >> >>

[PATCH RFA 2/2] drm/i2c: tda998x: add component support

On 07/24/2014 09:57 AM, Russell King wrote: > Add component helper support to the tda998x driver. This permits the > TDA998x to be declared as a separate device in device tree, and bound > at the appropriate moment with a co-operating card driver. > > The existing slave_encoder interfaces are

[PATCH RFA 1/2] drm/i2c: tda998x: allow re-use of tda998x support code

On 07/24/2014 09:57 AM, Russell King wrote: > Re-jig the TDA998x code so that we separate the functionality from the > drm slave encoder implementation. In several places, this is pretty > clearly the correct thing to do, because we can avoid repetitively > having to convert from the drm_encoder

[PATCH 12/12] drm: make sysfs device always available for minors

On Thu, Jul 24, 2014 at 12:48:49PM +0200, David Herrmann wrote: > Hi > > On Thu, Jul 24, 2014 at 12:36 PM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 05:26:47PM +0200, David Herrmann wrote: > >> For each minor we allocate a sysfs device as minor->kdev. Currently, this > >> is allocated and

[PATCH 11/12] drm: make minor->index available early

On Thu, Jul 24, 2014 at 12:16:59PM +0200, David Herrmann wrote: > Hi > > On Thu, Jul 24, 2014 at 12:03 PM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 05:26:46PM +0200, David Herrmann wrote: > >> Instead of allocating the minor-index during registration, we now do this > >> during

[PATCH 0/7] prepare for atomic.. the great propertyification

On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: > This is mostly just a rebase+resend. Was going to send it a bit earlier > but had a few things to fix up as a result of the rebase. > > At this point, I think next steps are roughly: > 1) introduce plane->mutex > 2) decide what we want

[PATCH] drm: Unlink dead file_priv from list of active files first

In order to prevent external observers walking the list of open DRM files from seeing an invalid drm_file_private in the process of being torndown, the first operation we need to take is to unlink the drm_file_private from that list. general protection fault: [#1] PREEMPT SMP

[pull] radeon drm-fixes-3.16

Hi Dave, Just a couple more small radeon fixes. The following changes since commit ec8a362f2e6e380e7a1f66a6c9a7f6c237ab3520: Merge branch 'drm-fixes-3.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-07-22 10:44:10 +1000) are available in the git repository at:

[PATCH v2 00/25] AMDKFD kernel driver

On Thu, Jul 24, 2014 at 11:44 AM, Jerome Glisse wrote: > On Thu, Jul 24, 2014 at 01:01:41AM +0300, Oded Gabbay wrote: >> On 24/07/14 00:46, Bridgman, John wrote: >> > >> >> -Original Message- From: dri-devel >> >> [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf Of Jesse >>

[PATCH 02/12] drm: drop unused "struct drm_queue"

Hi On Wed, Jul 23, 2014 at 9:35 PM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 05:26:37PM +0200, David Herrmann wrote: >> This object is unused, drop it. >> >> Signed-off-by: David Herrmann > > Funny how after even all my "kill stuff with fire" series there's still > such low hanging fruit

[PATCH 1/7] drm: add atomic fxns

Hi, >> { >> int ret = -EINVAL; >> -struct drm_connector *connector = obj_to_connector(obj); >> >> /* Do DPMS ourselves */ >> if (property == connector->dev->mode_config.dpms_property) { >> if (connector->funcs->dpms) >>

[PATCH 12/12] drm: make sysfs device always available for minors

Hi On Thu, Jul 24, 2014 at 12:36 PM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 05:26:47PM +0200, David Herrmann wrote: >> For each minor we allocate a sysfs device as minor->kdev. Currently, this >> is allocated and registered in drm_minor_register(). This makes it >> impossible to add

[PATCH 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

+CC: Thierry and Alexandre On 07/18/2014 12:56 PM, Inki Dae wrote: > This patch adds LPM transfer support for video or command data. > > With this patch, Exynos MIPI DSI controller can transfer command or > video data with HS or LP mode in accordance with mode_flags set > by LCD Panel driver. > >

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

On Thu, Jul 24, 2014 at 10:54:30AM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 24, 2014 at 11:47:55AM +0200, Lucas Stach wrote: > > Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo: > > > HDMI currently stops working after a system suspend/resume cycle. It > > > turns out

[PATCH 12/12] drm: make sysfs device always available for minors

On Wed, Jul 23, 2014 at 05:26:47PM +0200, David Herrmann wrote: > For each minor we allocate a sysfs device as minor->kdev. Currently, this > is allocated and registered in drm_minor_register(). This makes it > impossible to add sysfs-attributes to the device before it is registered. > Therefore,

[PATCH 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

Hi Inki, +CC: Thierry and Alexandre On 07/18/2014 12:56 PM, Inki Dae wrote: > This patch adds below two flags for LPM transfer, and it attaches LPM flags > to a msg in accordance with master's mode_flags set by LCD Panel driver. > > MIPI_DSI_MODE_CMD_LPM: low power command transfer >

[PATCH 04/12] drm: extract legacy ctxbitmap flushing

On Thu, Jul 24, 2014 at 11:34:45AM +0200, David Herrmann wrote: > Hi > > On Wed, Jul 23, 2014 at 9:26 PM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 05:26:39PM +0200, David Herrmann wrote: > >> The ctxbitmap code is only used by legacy drivers so lets try to keep it > >> as separated as

[PATCH 03/12] drm: call ->firstopen() before ->open()

On Thu, Jul 24, 2014 at 11:31:05AM +0200, David Herrmann wrote: > Hi > > On Wed, Jul 23, 2014 at 9:25 PM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 05:26:38PM +0200, David Herrmann wrote: > >> Lets order things correctly: > >> ->load() > >>->fistopen() > >> ->open() > >>

[PATCH 11/12] drm: make minor->index available early

Hi On Thu, Jul 24, 2014 at 12:03 PM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 05:26:46PM +0200, David Herrmann wrote: >> Instead of allocating the minor-index during registration, we now do this >> during allocation. This way, debug-messages between minor-allocation and >>

[PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

In my review of commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 Author: Rob Clark Date: Fri May 30 11:37:03 2014 -0400 drm: add object property typ I asked for a check to make sure that we never leak an fb from the generic mode object lookup since those have completely different lifetime

[PATCH 11/12] drm: make minor->index available early

On Wed, Jul 23, 2014 at 05:26:46PM +0200, David Herrmann wrote: > Instead of allocating the minor-index during registration, we now do this > during allocation. This way, debug-messages between minor-allocation and > minor-registration will now use the correct minor instead of 0. Same is > done

[PATCH 1/7] drm: add atomic fxns

property, value, blob_data); > + } Why the extra braces here? There's still only one statement in the block. > /** > - * drm_mode_getproperty_ioctl - get the current value of a object's property > + * drm_mode_obj_get_properties_ioctl - get the current value of a object's > property > * @dev: DRM device > * @data: ioctl data > * @file_priv: DRM file info This isn't really introduced by this patch, but isn't this kerneldoc comment wrong? drm_mode_obj_get_properties_ioctl() seems to return the values of all properties of an object rather than just one. 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/20140724/5122b236/attachment-0001.sig>

[Bug 75276] Implement VGPR Register Spilling

https://bugs.freedesktop.org/show_bug.cgi?id=78716#c10) -- You are receiving 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/20140724/2a40d8a9/attachment.html>

[PATCH 08/12] drm: don't de-authenticate clients on master-close

On Wed, Jul 23, 2014 at 05:26:43PM +0200, David Herrmann wrote: > If an active DRM-Master closes its device, we deauthenticate all clients > on that master. However, if an inactive DRM-Master closes its device, we > do nothing. This is quite inconsistent and breaks several scenarios: > > 1) If

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 242 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140724/453066e7/attachment-0001.sig>

[PATCH] [rfc] drm: close race in connector registration

From: Dave Airlie Daniel pointed out with hotplug that userspace could be trying to oops us as root for lols, and that to be correct we shouldn't register the object with the idr before we have fully set the connector object up. His proposed solution was a lot more life

[PATCH 07/12] drm: drop redundant drm_file->is_master

On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote: > The drm_file->is_master field is redundant as it's equivalent to: > drm_file->master && drm_file->master == drm_file->minor->master > > 1) "=>" > Whenever we set drm_file->is_master, we also set: >

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo: > HDMI currently stops working after a system suspend/resume cycle. It > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get > called from anywhere across suspend/resume cycle. > > The patch follows what exynos drm

[PATCH v2 00/25] AMDKFD kernel driver

On Thu, Jul 24, 2014 at 01:01:41AM +0300, Oded Gabbay wrote: > On 24/07/14 00:46, Bridgman, John wrote: > > > >> -Original Message- From: dri-devel > >> [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf Of Jesse > >> Barnes Sent: Wednesday, July 23, 2014 5:00 PM To: > >>

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

Hi Shawn, Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo: > HDMI currently stops working after a system suspend/resume cycle. It > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get > called from anywhere across suspend/resume cycle. > > The patch follows what

[PATCH 04/12] drm: extract legacy ctxbitmap flushing

Hi On Wed, Jul 23, 2014 at 9:26 PM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 05:26:39PM +0200, David Herrmann wrote: >> The ctxbitmap code is only used by legacy drivers so lets try to keep it >> as separated as possible. Furthermore, the locking is non-obvious and >> kinda weird with

[PATCH 3/4] drm/dsi: Make mipi_dsi_dcs_{read, write}() symmetrical

FIFO registers and start the transmission. > > This or just helpers in DSI host to calculate raw DSI data. I think either way would work. I slightly prefer the direct layering because we're implementing a standard protocol on top of another standard protocol. So it's fairly similar to networking protocols or even filesystems on top of the block layer. Therefore I think it makes sense to have an API that takes DCS inputs, such as command and payload, translates them to DSI and passes raw DSI to the driver, since presumably that's what the driver needs. That way we can move the protocol bits into common functions and let drivers do what they do best: interface with the hardware. > What about ECC? Should it be present also in tx buffer? ECC and CS are somewhat special. Hardware will probably provide a way to offload ECC and CS computations in the majority of cases, so it doesn't make much sense to compute them by default. I see two ways to achieve that: a) provide flags in struct mipi_dsi_host for supported features so that the protocol code can compute it if necessary or b) provide helpers that take a raw DSI packet and compute its CS or ECC. While I couldn't find an explicit reference to a CS or ECC enable bit, there also doesn't seem to be any code to compute it, so I assume it's always enabled (or at least by default). Tegra can also compute them in hardware, so I don't think we need to concern ourselves with that at this point. 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/20140724/5d4a823f/attachment.sig>

[PATCH 03/12] drm: call ->firstopen() before ->open()

Hi On Wed, Jul 23, 2014 at 9:25 PM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 05:26:38PM +0200, David Herrmann wrote: >> Lets order things correctly: >> ->load() >>->fistopen() >> ->open() >> ->close() >>->lastclose() >> ->unload() >> >> This doesn't change much as only

[PATCH] gpu: drm: omapdrm: Use %pad format for values of the dma_addr_t type

On Thu, 2014-07-24 at 21:58 +0400, matwey at sai.msu.ru wrote: > The format change is to fix the following compilation issue: Just a trivial note: > diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c > b/drivers/gpu/drm/omapdrm/omap_gem.c [] > @@ -791,7 +791,7 @@ int omap_gem_get_paddr(struct

[PATCH] [rfc] drm: close race in connector registration

Hi On Thu, Jul 24, 2014 at 10:49 AM, Dave Airlie wrote: >> >> This is the same we do for minor-objects, so fine with me. I'd prefer >> if the registration is done last in drm_connector_register(), not >> first, but I'm not sure the debugfs hooks work without the connector >> available in the

[PATCH 0/7] prepare for atomic.. the great propertyification

On Thu, Jul 24, 2014 at 10:00 AM, Daniel Vetter wrote: > On Thu, Jul 24, 2014 at 09:36:20AM -0400, Rob Clark wrote: >> On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: >> > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: >> >> This is mostly just a rebase+resend. Was going to

[PATCH] imx-drm: imx-drm-core: add suspend/resume support

On Thu, Jul 24, 2014 at 11:47:55AM +0200, Lucas Stach wrote: > Am Donnerstag, den 24.07.2014, 17:17 +0800 schrieb Shawn Guo: > > HDMI currently stops working after a system suspend/resume cycle. It > > turns out that the cause is the imx-hdmi encoder .dpms hook doesn't get > > called from

[PULL] drm-intel-fixes

Hi Dave, This time in time! Just 32bit-pae fix from Hugh, semaphores fun from Chris and a fix for runtime pm cherry-picked from next. Paulo is still working on a fix for runtime pm when X does cursor fun when the display is off, but that one isn't ready yet. Cheers, Daniel The following

[PATCH] [rfc] drm: close race in connector registration

Hi On Thu, Jul 24, 2014 at 3:53 AM, Dave Airlie wrote: > From: Dave Airlie > > Daniel pointed out with hotplug that userspace could be trying to oops us > as root for lols, and that to be correct we shouldn't register the object > with the idr before we have fully set the connector object up. >

[PATCH 3/4] drm/dsi: Make mipi_dsi_dcs_{read, write}() symmetrical

On 07/23/2014 03:37 PM, Thierry Reding wrote: > On Wed, Jul 23, 2014 at 12:59:46PM +0200, Andrzej Hajda wrote: >> On 07/23/2014 09:51 AM, Thierry Reding wrote: >>> On Tue, Jul 22, 2014 at 11:33:11AM +0200, Andrzej Hajda wrote: On 07/22/2014 10:12 AM, Thierry Reding wrote: > On Tue, Jul

[PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

In my review of commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 Author: Rob Clark Date: Fri May 30 11:37:03 2014 -0400 drm: add object property typ I asked for a check to make sure that we never leak an fb from the generic mode object lookup since those have completely different lifetime

[PATCH 03/12] drm: call ->firstopen() before ->open()

On Thu, Jul 24, 2014 at 5:31 AM, David Herrmann wrote: > Hi > > On Wed, Jul 23, 2014 at 9:25 PM, Daniel Vetter wrote: >> On Wed, Jul 23, 2014 at 05:26:38PM +0200, David Herrmann wrote: >>> Lets order things correctly: >>> ->load() >>>->fistopen() >>> ->open() >>> ->close() >>>

[PATCH 0/7] prepare for atomic.. the great propertyification

On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: >> This is mostly just a rebase+resend. Was going to send it a bit earlier >> but had a few things to fix up as a result of the rebase. >> >> At this point, I think next steps are

[PATCH] [rfc] drm: close race in connector registration

On Thu, Jul 24, 2014 at 11:53:45AM +1000, Dave Airlie wrote: > From: Dave Airlie > > Daniel pointed out with hotplug that userspace could be trying to oops us > as root for lols, and that to be correct we shouldn't register the object > with the idr before we have fully set the connector object

[PATCH 00/83] AMD HSA kernel driver

On Wed, Jul 23, 2014 at 04:57:48PM -0700, Jesse Barnes wrote: > On Sun, 13 Jul 2014 12:40:32 -0400 > j.glisse at gmail.com (Jerome Glisse) wrote: > > > On Sun, Jul 13, 2014 at 11:42:58AM +0200, Daniel Vetter wrote: > > > On Sat, Jul 12, 2014 at 6:49 PM, Jerome Glisse > > > wrote: > > > >> Hm,

[PATCH] gpio: extend gpiod_get*() with flags parameter

On Fri, Jul 25, 2014 at 12:04:58AM +0900, Alexandre Courbot wrote: > The huge majority of GPIOs have their direction and initial value set > right after being obtained by one of the gpiod_get() functions. The > integer GPIO API had gpio_request_one() that took a convenience flags > parameter

[PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

On Thu, Jul 24, 2014 at 09:54:27AM +0200, Daniel Vetter wrote: > In my review of > > commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 > Author: Rob Clark > Date: Fri May 30 11:37:03 2014 -0400 > > drm: add object property typ > > I asked for a check to make sure that we never leak an fb

[Bug 81001] radeon: fence wait failed (-35) after hybrid suspend, leading to GPU reset and hangs

https://bugzilla.kernel.org/show_bug.cgi?id=81001 Ivan Kalvachev changed: What|Removed |Added CC||iive at yahoo.com Regression|No

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140724/c8ebc8de/attachment.html>

[PATCH v2 00/25] AMDKFD kernel driver

On 24/07/14 00:46, Bridgman, John wrote: > >> -Original Message- From: dri-devel >> [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf Of Jesse >> Barnes Sent: Wednesday, July 23, 2014 5:00 PM To: >> dri-devel at lists.freedesktop.org Subject: Re: [PATCH v2 00/25] >> AMDKFD

[PATCH 1/7] drm: add atomic fxns

On Wed, Jul 23, 2014 at 11:34:00PM +0200, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 03:38:14PM -0400, Rob Clark wrote: > > The 'atomic' mechanism allows for multiple properties to be updated, > > checked, and commited atomically. This will be the basis of atomic- > > modeset and

[PATCH 1/7] drm: add atomic fxns

On Wed, Jul 23, 2014 at 03:38:14PM -0400, Rob Clark wrote: > The 'atomic' mechanism allows for multiple properties to be updated, > checked, and commited atomically. This will be the basis of atomic- > modeset and nuclear-pageflip. > > The basic flow is: > >state = dev->atomic_begin(); >