HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/3bb9e4fb/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130710/31a9c885/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/5ee61832/attachment.html>
On Wed, Jul 10, 2013 at 7:16 AM, Geert Uytterhoeven
wrote:
> drivers/gpu/drm/drm_edid_load.c: In function ?drm_load_edid_firmware?:
> drivers/gpu/drm/drm_edid_load.c:245: warning: initialization discards
> qualifiers from pointer target type
>
> drm_get_connector_name() returns a "const char *",
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter
wrote:
> We kzalloc the driver node at init time, so no need to do this again.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fops.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/dri
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/5ce610db/attachment.html>
Hi Daniel,
On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/26693b43/attachment.html>
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter
wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
>
> Cc: Andy Lutomirski
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm
Hi Dave,
These two patches fix compilation breakages in drm-next due to the removal of
drm_gem_cma_dmabuf_import() and drm_gem_cma_dmabuf_export() without updating
the existing users (I don't blame anyone here, the patch that removed those
functions and the patches that made use of them were merge
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +++--
1 file changed, 7 inser
The GEM CMA PRIME import/export helpers have been removed in favor of
generic GEM PRIME helpers with GEM CMA low-level operations. Fix the
driver accordingly.
Reported-by: Mark Brown
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 9 +++--
1 file changed, 7 in
https://bugs.freedesktop.org/show_bug.cgi?id=66767
--- Comment #2 from Johannes Hirte ---
It's a discrete only gpu, no hybrid. full dmesg output:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[
curate.
MPlayer interrupted by signal 11 in module: check_framedrop
--
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/20130710
his 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/20130710/1868b6e0/attachment.html>
Hi
On Wed, Jul 10, 2013 at 2:12 PM, Daniel Vetter
wrote:
> We might as well have a real ioctl function which checks for the
> callbacks. This seems to be a remnant from back in the days when each
> drm driver had their own complete ioctl table, with no shared core
> drm table at all.
>
> To make
;http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/2e000176/attachment.html>
On Wed, Jul 10, 2013 at 3:46 PM, Laurent Pinchart
wrote:
> On Wednesday 10 July 2013 13:54:33 Daniel Vetter wrote:
>> I've checked both implementations (radeon/nouveau) and they both grab
>> the page array from ttm simply by dereferencing it and then wrapping
>> it up with drm_prime_pages_to_sg in
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
> So after a bit of irc chatting with Maarten this seems to be more
> involved. The above check is to cache the dma mapping, but the
> implementation is bogus in tons of ways:
> - If direction changes we don't bother with unmaping and freeing the
> mapping, but simply leak it.
> - This will break i
On Wed, Jul 10, 2013 at 3:28 PM, David Herrmann
wrote:
> drm_setup() is called on every first open. I digged through core DRM
> and noticed that we have a lot of code that cleans up on lastclose and
> reinitializes on firstopen which is skipped for non-UMS drivers to
> preserve KMS state if no us
On Wed, Jul 10, 2013 at 5:18 PM, Konrad Rzeszutek Wilk
wrote:
>> So after a bit of irc chatting with Maarten this seems to be more
>> involved. The above check is to cache the dma mapping, but the
>> implementation is bogus in tons of ways:
>> - If direction changes we don't bother with unmaping a
On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
wrote:
>> -#if __OS_HAS_MTRR
>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>> -{
>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>> -}
>> -#else
>> -#define drm_core_has_MTRR(dev) (0)
>> -#endif
>> -
>
> That was th
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
Hi
On Wed, Jul 10, 2013 at 2:11 PM, Daniel Vetter
wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Com
Hi
On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
wrote:
> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
> wrote:
>>> -#if __OS_HAS_MTRR
>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
>>> -{
>>> - return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>>> -}
>>> -#else
Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 1 -
include/drm/drmP.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index d1b4771..5679971 100644
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann
wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
> wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>> wrote:
-#if __OS_HAS_MTRR
-static inline int drm_core_has_MTRR(struct drm_device *dev)
-{
- return d
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected driver
I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 29 -
1 file changed, 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Document
Op 10-07-13 16:48, Daniel Vetter schreef:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grab
On Wed, Jul 10, 2013 at 6:27 PM, Andy Lutomirski wrote:
> Are all of those codepaths really inaccessible in non-legacy drm
> drivers? I didn't try to fully unravel all the ioctls and such, but
> it seems like userspace could add bufs and map them. Since the mtrr
> code isn't very robust (referen
--
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/20130710/9e80dc02/attachment.html>
From: Mark Brown
The driver uses CMA APIs so won't link if CMA is not being built.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/rcar-du/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 72887df..
res them.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/345853c6/attachment-0001.pgp>
igital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/f571c78a/attachment-0001.pgp>
On 7/10/2013 2:09 AM, Daniel Vetter wrote:
> On Wed, Jul 10, 2013 at 04:01:49PM +1000, Dave Airlie wrote:
>> On Wed, Jul 10, 2013 at 7:45 AM, Rhyland Klein wrote:
>>> We are currently looking into exporting some information from the linux
>>> kernel to userspace about the GPU. This information is
On Wed, Jul 10, 2013 at 8:59 AM, Daniel Vetter
wrote:
> On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann
> wrote:
>> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter
>> wrote:
>>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>>> wrote:
> -#if __OS_HAS_MTRR
> -static inline int drm_c
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c |6 --
driver
Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
MTRR code" contains the following change:
@@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
}
}
+if (mtrr != 3 && mtrr != 1)
+pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
unsupported
Hi
On Tue, Jul 9, 2013 at 11:02 PM, Stephen Warren
wrote:
> On 07/04/2013 06:25 AM, David Herrmann wrote:
>> Hi
>>
>> This series changes the way we handle firmware framebuffers on x86 systems.
>> On
>> other architectures the recently introduced "simple-framebuffer"
>> platform-devices provide
On Wed, Jul 10, 2013 at 7:07 PM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
v2: Don't forge
https://bugzilla.kernel.org/show_bug.cgi?id=57381
Harald Judt changed:
What|Removed |Added
Kernel Version||3.8.13
--- Comment #21 from Harald Judt --
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging
g/archives/dri-devel/attachments/20130710/7d2d22b9/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130710/135e8e29/attachment-0001.html>
unmapped
Advanced Joystick settings initialized
Redownloading all lightmaps
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Uploading dump (out-of-process) [proxy '']
/tmp/dumps/assert_20130711011649_1.dmp
/home/lordh/.local/share/Steam/SteamApps/common/Portal/hl2.sh : ligne 67 :
14112 Abandon (core dumped)${GAME_DEBUGGER}
"${GAMEROOT}"/${GAMEEXE} "$@"
Game removed: AppID 400 "Portal", ProcID 14112
-->8--
--
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/20130710/37813f27/attachment.html>
On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
wrote:
> Hello,
>
> I'm trying to understand how TTM buffer object mapping works on Linux, to
> make this behave properly on FreeBSD.
>
> Here's what I think I understand:
>
> When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When
On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
201 - 254 of 254 matches
Mail list logo
