Hi
On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski
wrote:
> A quick grep of the kernel tree finds exactly zero code paths
> incrementing i_mmap_writable outside of mmap and fork.
>
> Or do you mean a different kind of write ref? What am I missing here?
Sorry, I meant i_writecount.
Thanks
Da
Hi
On Fri, Apr 11, 2014 at 7:43 PM, Daniel Vetter wrote:
> Hm, my plan was actually to just provide a drm_dev_setunique to drivers so
> that they can set whatever their userspace wants, and then have no
> set_busid implementation here at all for !pci. Some userspace at least
> uses the unique thi
Especially not on modesetting drivers - this is used to size
the driver private structure for legacy drm buffers.
Reviewed-by: Damien Lespiau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/radeon/radeon_drv.
With the last patch to ditch the ->get_name callbacks the last
user is now gone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 1 -
drivers/gpu/drm/drm_platform.c | 1 -
drivers/gpu/drm/drm_usb.c | 1 -
include/drm/drmP.h | 5 -
4 files changed, 8 deletio
The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.
The exception is usb, which used a ge
This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.
Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So
This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.
v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.
Signed-off-by: Daniel Vetter
-
Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 6 --
drivers/gpu/drm/drm_platform.c | 6 --
drivers/gpu/drm/drm_usb.c | 6 --
include/drm/drmP.h | 1 -
4
Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.
With that we can now also remove drm_dev_to_irq from drm_irq.c.
Signed-off-by:
It's only ever called for legacy drivers, which are all pci.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1c3b6229363d..a83b037f5615 100644
--- a/dr
To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.
v2: Add the hunk lost in an earlier patch to this on
Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.
v2: Move the spurious hunk to the right patch (Thierry).
Cc: Thierry Reding
So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.
Unfortunately the vga switcheroo callbacks took this commen
Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!
v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 1 -
drivers/gpu/drm/drm_platform.c | 1 -
drivers/gpu/drm/drm_usb.c |
Only used in some legacy pci drivers, and dereferncing the pci irq is
actually shorter ...
Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c
The dev->struct_mutex locking in drm_irq.c only protects
dev->irq_enabled. Which isn't really much at all and only prevents
especially nasty ums userspace from concurrently installing the
interrupt handling a few times. Or at least trying.
There are tons of unlocked readers of dev->irqs_enabled in
This just adds a correspdonding check, follow-up patches will exploit
this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c02b602325cb..4b
This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.
To keep things work without CONFIG_PCI also add a dummy ioctl.
v2: Block the irq_by_busid ioctl for modeset dr
Checking for both an irq number _and_ whether it's enabled is
redundant. Originally I've thought the drm_dev_to_irq call would break
drivers which do their own irq checking, but those shouldn't have
DRIVER_HAVE_IRQ set as Thierry Reding pointed out. But such drivers
already need to set dev->irq_ena
Dave accidentally merged the wrong version of the patch in
commit fd3c02531461924853db65f2664db361b53a70d3
Author: Daniel Vetter
Date: Wed Dec 11 11:34:26 2013 +0100
drm/omap: call drm_put_dev directly in ->remove
which did not include the fix from Rob's review: omapdrm is split into
the
Hi all,
I've chatted a bit with Thierry about how we could allow drivers to not even
required a drm_bus any more. Which is relevant when e.g. due to the new
master/component no platform device is conveniently around.
So I've brushed off my old series to remove some drm_bus functions and other
cru
Hi
On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby
wrote:
> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
> from blkdev_direct_IO().
If you drop mmap_sem after pinning a page without taking a write
On Fri, Apr 11, 2014 at 8:30 PM, Thierry Reding
wrote:
> On Fri, Apr 11, 2014 at 07:43:18PM +0200, Daniel Vetter wrote:
>> On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
> [...]
>> > - ret = dev->driver->bus->set_busid(dev, master);
>> > - if (ret)
>> > - goto err;
>
On 04/11/2014 10:31 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom
> wrote:
>> as was discussed a while ago, there are some serious security flaws with
>> the current drm master model, that allows a
>> user that had previous access or current access to an X s
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/794223bb/attachment-0001.html>
Hi
On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom
wrote:
> as was discussed a while ago, there are some serious security flaws with
> the current drm master model, that allows a
> user that had previous access or current access to an X server terminal
> to access the GPU memory of the active
y checked. There's no new mc ucode for cayman.
--
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/20140411/2cb29284/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/d7f02f81/attachment.html>
dri-devel/attachments/20140411/7410d9c0/attachment.html>
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/20140411/944f0a04/attachment.html>
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
> op 11-04-14 12:11, Thomas Hellstrom schreef:
>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>>> op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
Fi
Hi!
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
> op 11-04-14 12:11, Thomas Hellstrom schreef:
>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>>> op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
>>
-)
Cheers.
--
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/20140411/38420281/attachment.html>
.
--
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/20140411/a29bf4d3/attachment.html>
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> > On Fri, 11 Apr 2014 10:33:08 +0200
> > Christian K?nig wrote:
> >
> Actually direct register access shouldn't be necessary so often. Apart
> from page flips, write/read pointer u
t was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/c5eafc0d/attachment.sig>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/65e24f3d/attachment.html>
op 11-04-14 12:11, Thomas Hellstrom schreef:
> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>> op 11-04-14 10:38, Thomas Hellstrom schreef:
>>> Hi, Maarten.
>>>
>>> Here I believe we encounter a lot of locking inconsistencies.
>>>
>>> First, it seems you're use a number of pointers as RCU point
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/065c95bc/attachment.html>
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Anyway, I would do like Ilia suggested and only put the else branch into
> a separate, not inlined function.
>
> BTW: It's probably a good idea to do the same for the write function as
> well.
I tested it. The majority of the size in
On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The only reason why struct drm_bus is still around is because the
> SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
> provides a fallback implementation if a device either doesn't h
On 04/11/2014 06:58 PM, Jani Nikula wrote:
> On Fri, 11 Apr 2014, Aaron Lu wrote:
>> On 04/11/2014 04:13 AM, Matthew Garrett wrote:
>>> The list of machines in the "Use native backlight" table is getting longer
>>> and longer, which is a solid indication that we're doing something wrong.
>>> Disab
On Fri, Apr 11, 2014 at 5:15 PM, Thomas Hellstrom
wrote:
> On 04/11/2014 10:31 PM, David Herrmann wrote:
>> Hi
>>
>> On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom
>> wrote:
>>> as was discussed a while ago, there are some serious security flaws with
>>> the current drm master model, that al
On Thu, Apr 10, 2014 at 5:33 AM, Andreas Noever
wrote:
> 457e77b2 effectively replaces (... & 0xff00) << 8 with (... >> 8) << 8.
> Which does not do the same and breaks boot on my machine.
>
> Restore the old behaviour and remove the unnecessary cast.
>
> Signed-off-by: Andreas Noever
Signed-
On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot wrote:
> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>> wrote:
>>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
GK20A's timer is directly attached to the syste
07:59:47 (GMT)
--
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/20140411/27846a73/attachment-0001.html>
Am 11.04.2014 17:21, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> v2: print out mc firmware version used and size
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
All three added to my drm-fixes-3.15 queue.
Christian.
> ---
> drivers/gpu/drm/radeon
From: Christian K?nig
Letting post and refernce divider get to big is bad for signal stability.
v2: increase the limit to 210
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display
Am 11.04.2014 16:52, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
Why adding *_mc2.bin for the MC firmware? To distinct if people have the
new or the old firmware?
If that's the case I would rather print
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong
---
drivers/gpu/drm/tegra/gem.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bc
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu
On 04/11/2014 04:31 PM, Ben Skeggs wrote:
> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot
> wrote:
>> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>>> wrote:
On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>
The patch adds function to block/unblock drm master device initialization.
exynos_drm_dev_ready(pdev, bool) informs exynos_drm core if given device is
ready. exynos_drm master is initialized only if all devices are ready,
exynos_drm master is also removed if any device becomes not ready.
During mod
The patch removes driver registration code based on preprocessor conditionals.
Instead it uses private linker section to create array of drm drivers.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/Makefile | 2 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
driver
Hi Inki,
This patchset refactors drm device initialization. Details are described
in respective patches. It is an alternative to DT supernode concept.
The first patch uses linker sections to get rid of ifdef macros, it is not
essential for 2nd patch but it makes code more readable. Similar approa
1 deletion(-)
Reviewed-by: Thierry Reding
Tested-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/27e08315/attachment.sig>
From: Thierry Reding
The only reason why struct drm_bus is still around is because the
SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
provides a fallback implementation if a device either doesn't have a bus
associated with it or if it doesn't implement .set_busid(). The
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140411/06613f01/attachment.html>
Am 11.04.2014 04:29, schrieb Alex Deucher:
> Don't try and runtime suspend the APU in PX systems. We
> only want to power down the dGPU.
>
> v2: fix harder
> v3: fix stupid typo
> v4: consolidate runpm enablement to a single flag
>
> bugs:
> https://bugs.freedesktop.org/show_bug.cgi?id=75127
> htt
On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann
wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski
> wrote:
>> A quick grep of the kernel tree finds exactly zero code paths
>> incrementing i_mmap_writable outside of mmap and fork.
>>
>> Or do you mean a different kind of write re
> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 11:03 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH 1/3] drm/radeon: add support for newer mc
On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, jus
Hi,
as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current access to an X server terminal
to access the GPU memory of the active X server, without being
authenticated to the X server and thereby
On 04/11/2014 02:31 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby
> wrote:
>> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
>> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
>> from blkdev_direct_IO().
>
> If
Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> On Fri, 11 Apr 2014 10:33:08 +0200
> Christian K?nig wrote:
>
Actually direct register access shouldn't be necessary so often. Apart
from page flips, write/read pointer updates and irq processing there
shouldn't be so many of them. Could
ing 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/20140411/8fbee770/attachment.html>
By the time drm_mode_config_cleanup calls this all the hw state should
be cleaned up already - we even have a WARN right before calling
plane->destroy callbacks asserting that all framebuffers are gone.
So trying to disable things harder is a bit a bug. Caught by Thierry
since it resulted in some
For Z order property we have take example on exynos driver and keep
the same property name to avoid forking.
I would prefer to not hardcode Z order because we use it to do a kind
of composition between graphical planes and video planes.
It allow us to manage the Z order of some windows without usi
|--- |WORKSFORME
--
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/20140411/7a82263e/attachment.html>
On Fri, 11 Apr 2014, Aaron Lu wrote:
> On 04/11/2014 04:13 AM, Matthew Garrett wrote:
>> The list of machines in the "Use native backlight" table is getting longer
>> and longer, which is a solid indication that we're doing something wrong.
>> Disable the ACPI backlight interface if the system cla
This patch adds configuration of SiI9234 bridge to Trats2 board.
Signed-off-by: Tomasz Stanislawski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exyn
Add driver for HDMI bridge using MHL connection.
Contains refactored code for MHL driver developed by:
Adam Hampson
Erik Gilling
Shankar Bandal
Dharam Kumar
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
Documentation/devicetree/bindings/sii9234.txt | 22 +
drivers/m
Hi everyone,
This patchset adds support for sii9234 HD Mobile Link Bridge. The chip is used
to convert HDMI signal into MHL. The driver enables HDMI output on Trats and
Trats2 boards.
The code is based on the driver [1] developed by:
Adam Hampson
Erik Gilling
with additional cont
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/e26a4627/attachment.html>
ani Nikula, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/d387c829/attachment.sig>
> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 9:10 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: fix runpm handling on APUs (v
--
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/20140411/39a5550d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140411/9fb71e7e/attachment.html>
vel/attachments/20140411/200edc27/attachment-0001.html>
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/24d63132/attachment.html>
On Fri, 11 Apr 2014 10:33:08 +0200
Christian K?nig wrote:
> >> Actually direct register access shouldn't be necessary so often. Apart
> >> from page flips, write/read pointer updates and irq processing there
> >> shouldn't be so many of them. Could you clarify a bit more what issue
> >> you are s
The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.
Use the same spinlock in page_flip, to make sure the above omap_c
omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.
Initialize old_fb to the fb that we intend to flip to through page_fl
The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are
greater than what is specified in the driver through dev->mode_config.
Create helpers for DISPC which return the max manager width and height supported
by the device. The maximum width for a framebuffer is set to the com
The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.
Reported-by: Somnath Mukherjee
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 1 +
1 file changed, 1 ins
A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.
Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.
This sho
From: Subhajit Paul
In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to
be free'd in the function itself.
Make sure we free the waiter for this case.
Signed-off-by: Subhajit Paul
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_gem.c | 2 ++
1 file cha
These are based over Tomi's 3.15/omapdrm-fixes branch.
Archit Taneja (5):
drm/omap: gem sync: wait on correct events
drm/omap: Fix crash when using LCD3 overlay manager
drm/omap: Allow allocation of larger buffers
drm/omap: Use old_fb to synchronize between successive page flips
drm/omap
https://bugzilla.kernel.org/show_bug.cgi?id=50091
--- Comment #33 from Dzianis Kahanovich ---
Created attachment 131911
--> https://bugzilla.kernel.org/attachment.cgi?id=131911&action=edit
patch: port from <3.7
Try this patch. I have some happy uptime (I have this Gigabyte mb on work
desktop a
On Friday 11 April 2014 12:10 PM, Tomi Valkeinen wrote:
>> Does drm_framebuffer_remove get called when we abort the application, or
>> unload omapdrm, or both?
>
> Both. When we abort an app, drm_framebuffer_remove gets called for the
> fb that the app created. When we unload omapdrm, it gets ca
On Tue, Apr 08, 2014 at 02:19:24PM +0200, Benjamin Gaignard wrote:
> Make the link between all the hardware drivers and DRM/KMS interface.
> Create the driver itself and make it register all the sub-components.
> Use GEM CMA helpers for buffer allocation.
>
> Signed-off-by: Benjamin Gaignard
> Si
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/20140411/8e51c62f/attachment.html>
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
> op 11-04-14 10:38, Thomas Hellstrom schreef:
>> Hi, Maarten.
>>
>> Here I believe we encounter a lot of locking inconsistencies.
>>
>> First, it seems you're use a number of pointers as RCU pointers without
>> annotating them as such and use the co
Hi,
On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, just a
linux-git
'Tested-by: Ed Tomlinson '
THANKS!
--
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/20140411/d2f0200e/attachment.html>
On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>>> GK20A's timer is directly attached to the system timer and cannot be
>>> calibrated. Skip the calibration phase o
On Fri, Apr 11, 2014 at 11:24 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Letting post and refernce divider get to big is bad for signal stability.
>
> v2: increase the limit to 210
Maybe mention the bug number?
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
>
op 11-04-14 10:38, Thomas Hellstrom schreef:
> Hi, Maarten.
>
> Here I believe we encounter a lot of locking inconsistencies.
>
> First, it seems you're use a number of pointers as RCU pointers without
> annotating them as such and use the correct rcu
> macros when assigning those pointers.
>
> Som
If the new mc ucode is available.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 18e91ee..10dae41 100
1 - 100 of 144 matches
Mail list logo
