On 16 May 2014 23:54, Christian K?nig wrote:
> Hi Dave,
>
> this is the next pull quested for stashed up radeon fixes for 3.15.
>
> Highlights are:
> 1. Avoid sending SIGBUS on CPU access just because kernel can't handle
> buffer placement.
> 2. Some fixes for VM page table updates and buffer plac
3 4
Observed: 2 3 1 4
--
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/20140519/084155d9/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/da5aa229/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75401
--- Comment #13 from Alex Deucher ---
(In reply to Pali Roh?r from comment #12)
> @Alex Deucher: Why is this bug while loop needed?
IIRC, sometimes the method is hung off the other GPU.
--
You are receiving this mail because:
You are watching t
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/9682ceea/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/0ac734cd/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/20140519/6b5d7d21/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/6681743a/attachment-0001.html>
Fix a very shameful memory leak and a compilation error due to the use of
non-exported CMA functions. The workaround for the latter is not really elegant
(replace the CMA functions by a runtime failure if we are compiled as a
module), but is temporary and still an improvement over the current situa
CMA-allocated memory must be freed by an exact mirror call to
dma_release_from_contiguous(). It cannot be freed page-by-page as was
previously believed without severe memory leakage.
This page records the address and size of every allocated memory chunk
so they can be properly freed when needed.
CMA functions are not available to kernel modules, but the GK20A FB
driver currently (and temporarily) relies on them.
This patch replaces the calls to CMA functions in problematic cases (CMA
enabled and Nouveau compiled as a module) with dummy stubs that will
make this particular driver fail, but
The current user of the coloring will adjust the end points of the node
to leave a hole between disjoint memory types. This adjustment must be
performed first or else the derived size will conflict with the
adjustment and trigger the BUG_ON sanity checks that the node is within
bounds.
Fixes regre
On 16 May 2014 20:19, Tomasz Figa wrote:
> On 16.05.2014 16:30, Rahul Sharma wrote:
>> On 16 May 2014 16:20, Tomasz Figa wrote:
>>> On 16.05.2014 12:35, Rahul Sharma wrote:
On 16 May 2014 15:12, Rahul Sharma wrote:
> On 16 May 2014 03:14, Tomasz Figa wrote:
>> On 15.05.2014 06:01,
This small series introduces TTM helper functions as well as Nouveau hooks that
are needed to ensure buffer coherency on ARM. Most of this series is a
forward-port of some patches Lucas Stach sent last year and that are also
needed for Nouveau GK20A support:
http://lists.freedesktop.org/archives/n
From: Lucas Stach
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1df856f78568..30e5d90cb7bc 100644
From: Lucas Stach
On arches with non-coherent PCI, we need to flush caches ourselfes at
the appropriate places. Introduce two small helpers to make things easy
for TTM based drivers.
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/ttm/ttm_tt.c| 25 +
From: Lucas Stach
Signed-off-by: Lucas Stach
[acourbot at nvidia.com: make conditional and platform-friendly]
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 32
drivers/gpu/drm/nouveau/nouveau_bo.h | 20
drive
Some architectures (e.g. ARM) need the CPU buffers to be explicitely
flushed for a memory write to take effect. Not doing so results in
synchronization issues, especially after writing to BOs.
This patch introduces a macro that flushes the caches on ARM and
translates to a no-op on other architect
On Fri, May 16, 2014 at 03:36:47PM -0700, Matt Roper wrote:
> Refactor DRM framebuffer creation into a new function that returns a
> struct drm_framebuffer directly. The upcoming universal cursor support
> will want to create framebuffers internally to wrap cursor buffers, so
> we want to be able
On Fri, May 16, 2014 at 03:36:48PM -0700, Matt Roper wrote:
> Refactor DRM setplane code into a new setplane_internal() function that
> takes DRM objects directly as parameters rather than looking them up by
> ID. We'll use this in a future patch when we implement legacy cursor
> ioctls on top of
On Sun, May 18, 2014 at 02:24:50AM +0200, Robin Schroer wrote:
> Fixed several switch statements, curly braces, dereference operators
> and keywords.
>
> Signed-off-by: Robin Schroer
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 --
I didn't spot anything else, so with the below issue addressed this patch
is Reviewed-by: Daniel Vetter
On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
> On Sat, May 17, 2014 at 12:38 AM, Matt Roper
> wrote:
> > + if (ret) {
> > + if (req->flags & DRM_MODE_CUR
On 11 April 2014 07:22, Rahul Sharma wrote:
> Thanks Tomasz,
>
> This patch is not longer required after rebasing to Tomasz Stanislawski's
> Simple Phy patches.
>
Hi All,
We had further discussion on the "Simple Phy Driver" at
http://www.spinics.net/lists/linux-samsung-soc/msg31100.html. The
dis
op 15-05-14 18:13, Christian K?nig schreef:
> Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
>> op 15-05-14 17:48, Christian K?nig schreef:
>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian K?nig schreef:
> Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
>>>
On Mon, May 19, 2014 at 07:52:37AM +0100, Chris Wilson wrote:
> The current user of the coloring will adjust the end points of the node
> to leave a hole between disjoint memory types. This adjustment must be
> performed first or else the derived size will conflict with the
> adjustment and trigger
On Mon, May 19, 2014 at 10:14:27AM +0200, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 07:52:37AM +0100, Chris Wilson wrote:
> > The current user of the coloring will adjust the end points of the node
> > to leave a hole between disjoint memory types. This adjustment must be
> > performed first o
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
> op 15-05-14 18:13, Christian K?nig schreef:
>> Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
>>> op 15-05-14 17:48, Christian K?nig schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
> op 15-05-14 15:19, Christian K?nig schreef:
>>>
scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/ff67b2bc/attachment.sig>
has both variants of
the nouveau_bo_sync_for_*() calls in the same file.
Thierry
------ 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/20140519/a9b3c9d4/attachment.sig>
2014-05-13 17:30 GMT+02:00 Thierry Reding :
> From: Thierry Reding
>
> Instead of the current implementation, reuse the recently introduced
> master/component framework, which is equivalent in most regards. One
> issue is that there is no device to bind the DRM driver to. In order
> to still allow
h the cache after all the writes have completed?
Thierry
-- 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/20140519/a1b385f2/attachment.sig>
Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
> > Some architectures (e.g. ARM) need the CPU buffers to be explicitely
> > flushed for a memory write to take effect. Not doing so results in
> > synchronization iss
This patch series is the final (?) step towards the initial support of GK20A,
allowing it to be probed and used (currently at a very slow speed, and for
offscreen rendering only) on the Jetson TK1 and Venice 2 boards.
The main piece if the first patch which adds platform devices probing support
to
Add a platform driver for Nouveau devices declared using the device tree
or platform data. This driver currently supports GK20A on Tegra
platforms and is only compiled for these platforms if Nouveau is
enabled.
Nouveau will probe the chip type itself using the BOOT0 register, so all
this driver re
Add the device tree binding documentation for the GK20A GPU used in
Tegra K1 SoCs.
Signed-off-by: Alexandre Courbot
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/nvidi
From: Thierry Reding
Add the GK20A device node to Tegra124's device tree.
Signed-off-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra124.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts
From: Thierry Reding
Signed-off-by: Thierry Reding
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra124-venice2.dts | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
b/arch/arm/boot/dts/tegra124-venice2.dts
index f0bb8
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index e31fb61a81d3..15a194d1277f 100644
--- a/arch/arm/b
Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
> From: Lucas Stach
>
> Signed-off-by: Lucas Stach
> [acourbot at nvidia.com: make conditional and platform-friendly]
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 32
Am Montag, den 19.05.2014, 10:46 +0200 schrieb Thierry Reding:
> On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
> > From: Lucas Stach
> >
> > Signed-off-by: Lucas Stach
> > [acourbot at nvidia.com: make conditional and platform-friendly]
> > Signed-off-by: Alexandre Courbot
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable solution could be.
Allowing BOs to be write-cached results in the following happening when
trying to run any program on Tegra/GK20A:
Unhandled fault: external abort on non-linefetch
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/71e2fc30/attachment.html>
Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
> This patch is not meant to be merged, but rather to try and understand
> why this is needed and what a more suitable solution could be.
>
> Allowing BOs to be write-cached results in the following happening when
> trying to run an
ng back a lot from those
> buffers.
> Using the write-combining buffer doesn't need any additional
> synchronization as it will get flushed on pushbuf kickoff anyways.
Sounds good to me.
Thierry
-- 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/20140519/83d18f32/attachment.sig>
Am Montag, den 19.05.2014, 18:24 +0900 schrieb Alexandre Courbot:
> This patch series is the final (?) step towards the initial support of GK20A,
> allowing it to be probed and used (currently at a very slow speed, and for
> offscreen rendering only) on the Jetson TK1 and Venice 2 boards.
>
This s
On 05/19/2014 06:57 PM, Lucas Stach wrote:
> Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
>> This patch is not meant to be merged, but rather to try and understand
>> why this is needed and what a more suitable solution could be.
>>
>> Allowing BOs to be write-cached results in
but let me clarify again and get back to you.
Thierry
-- 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/20140519/3baba6dc/attachment-0001.sig>
op 19-05-14 10:27, Christian K?nig schreef:
> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>> op 15-05-14 18:13, Christian K?nig schreef:
>>> Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian K?nig schreef:
> Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
>>>
Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot:
> On 05/19/2014 06:57 PM, Lucas Stach wrote:
> > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
> >> This patch is not meant to be merged, but rather to try and understand
> >> why this is needed and what a more su
On Mon, May 19, 2014 at 09:21:23AM +0100, Chris Wilson wrote:
> On Mon, May 19, 2014 at 10:14:27AM +0200, Daniel Vetter wrote:
> > On Mon, May 19, 2014 at 07:52:37AM +0100, Chris Wilson wrote:
> > > The current user of the coloring will adjust the end points of the node
> > > to leave a hole betwee
On Mon, May 19, 2014 at 07:52:37AM +0100, Chris Wilson wrote:
> The current user of the coloring will adjust the end points of the node
> to leave a hole between disjoint memory types. This adjustment must be
> performed first or else the derived size will conflict with the
> adjustment and trigger
On Mon, May 19, 2014 at 12:03:17PM +0200, Thierry Reding wrote:
> On Mon, May 19, 2014 at 11:22:11AM +0200, Lucas Stach wrote:
> > Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding:
> > > On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote:
> > > > Some architectures (e.g.
https://bugzilla.kernel.org/show_bug.cgi?id=75931
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
https://bugzilla.kernel.org/show_bug.cgi?id=75921
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
This set of independent patches contains various improvement and fixes
for exynos_drm ipp framework and drivers.
The patchset is based on drm-exynos/exynos-drm-next branch.
Regards
Andrzej
Andrzej Hajda (8):
drm/exynos/ipp: fix get_property IOCTL
drm/exynos/ipp: correct ipp_id field initiali
Due to incorrect assignment in EXYNOS_IPP_GET_PROPERTY
IOCTL handler this IOCTL did not work at all.
The patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_
prop_list.ipp_id field is not initialized properly.
The patch fixes it, additionally it removes redundant field from ippdrv.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 1 -
2 files changed, 6 insertions
prop_list is always allocated, so instead of allocating it dynamically
the pointer can be replaced by the structure itself.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 10 ++
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 10 ++
drivers/gpu/drm/e
The patch replaces dedicated function for scaling ratio
calculation by fls calls.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 56
1 file changed, 13 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fim
Function fimc_dst_set_buf_seq is called by irq handler
so it should not use mutexes. This patch fixes it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fi
The name fimc_handle_irq suggests it is irq handler, but the function
is for irq mask configuration. The patch renames the function to
fimc_mask_irq and removes unused arguments.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 25 +
1 file chan
HW access macros implicitly depended on presence of ctx local variable.
This patch replaces them with C functions.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 311 +++
1 file changed, 150 insertions(+), 161 deletions(-)
diff --git a/dr
fimc_dst_get_buf_seq returns number of buffers
so the name should be fimc_dst_get_buf_count.
Function body has been simplified.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu
On 19.05.2014 09:10, Rahul Sharma wrote:
> On 16 May 2014 20:19, Tomasz Figa wrote:
>> On 16.05.2014 16:30, Rahul Sharma wrote:
>>> On 16 May 2014 16:20, Tomasz Figa wrote:
On 16.05.2014 12:35, Rahul Sharma wrote:
> On 16 May 2014 15:12, Rahul Sharma wrote:
>> On 16 May 2014 03:14,
Hi
On Wed, May 14, 2014 at 3:58 PM, Jani Nikula wrote:
> This makes drm_get_connector_name() thread safe.
>
> Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at
> DC1-MBX-01.ptsecurity.ru
> Signed-off-by: Jani Nikula
I like that approach, but we should also kill drm_get_co
Hi
CC: Dave & Daniel
On Wed, May 14, 2014 at 3:58 PM, Jani Nikula wrote:
> Hi all -
>
> This series stores connector/encoder names in the relevant structs to
> make the name getters thread safe.
>
> What say you, is the wasted memory too high a price to pay for the
> thread safety and implementa
--
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/20140519/34d68798/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75301
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/a1b29995/attachment.html>
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
> op 19-05-14 10:27, Christian K?nig schreef:
>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>> [SNIP]
>> The problem here is that the whole approach collides with the way we
>> do reset handling from a conceptual point of view. Every IOCTL or
>
https://bugzilla.kernel.org/show_bug.cgi?id=74551
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You are receiving this mail because:
Hi
On Wed, May 14, 2014 at 3:58 PM, Jani Nikula wrote:
> This makes drm_get_encoder_name() thread safe.
>
> Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at
> DC1-MBX-01\
> .ptsecurity.ru
> Signed-off-by: Jani Nikula
Same as for 1/2, a followup would be nice.
Reviewed-b
op 19-05-14 14:30, Christian K?nig schreef:
> Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
>> op 19-05-14 10:27, Christian K?nig schreef:
>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
>>> [SNIP]
>>> The problem here is that the whole approach collides with the way we do
>>> reset handling
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_sysfs.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index c22c309..257816e 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
> This adds 4 more functions to deal with rcu.
>
> reservation_object_get_fences_rcu() will obtain the list of shared
> and exclusive f
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/e7b2c590/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/4ad3ceb5/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75301
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, May 19, 2014 4:50 AM
> To: Dave Airlie
> Cc: Deucher, Alexander; dri-devel at lists.freedesktop.org
> Subject: Re: [pull] radeon drm-fixes-3.15
>
> Am 19.05.2014 01:04, schrieb Dave Airlie:
> > On 16 May 2014 23:54, Christian K
https://bugzilla.kernel.org/show_bug.cgi?id=75301
--- Comment #2 from Alex Deucher ---
This is a duplicate bug 75401.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75931
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=75931
--- Comment #2 from Alex Deucher ---
duplicate of bug 75921.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75921
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
op 19-05-14 15:42, Thomas Hellstrom schreef:
> Hi, Maarten!
>
> Some nitpicks, and that krealloc within rcu lock still worries me.
> Otherwise looks good.
>
> /Thomas
>
>
>
> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
>> @@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
>> reserv
Hi
On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
The commit-msg lacks any discussion why this change is done. What is
the reason to do that? Isn't the kernel-command-line enough? Why is
this a regular feature instead of a debugfs attribute?
> ---
> drivers/g
Am 19.05.2014 15:35, schrieb Maarten Lankhorst:
> op 19-05-14 14:30, Christian K?nig schreef:
>> Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
>>> op 19-05-14 10:27, Christian K?nig schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole a
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #5 from Alex Deucher ---
(In reply to Pali Roh?r from comment #4)
>
> And for power_dpm_state & power_dpm_force_performance_level: I understand
> that it cannot be changed when card is turned off (I see that it also
> disappear from P
On Sat, May 10, 2014 at 6:17 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> This patch implements support for VRAM page table entry compression.
> PTE construction is enhanced to identify physically contiguous page
> ranges and mark them in the PTE fragment field. L1/L2 TLB support is
> e
On Sat, May 17, 2014 at 10:16 PM, Dieter N?tzel wrote:
> Hello Christian,
>
> no one has picked this.
> http://lists.freedesktop.org/archives/dri-devel/2014-May/059189.html
>
> Even Alex ACKed it.
> http://lists.freedesktop.org/archives/dri-devel/2014-May/059191.html
Christian, can you grab this
Am 19.05.2014 16:36, schrieb Alex Deucher:
> On Sat, May 17, 2014 at 10:16 PM, Dieter N?tzel
> wrote:
>> Hello Christian,
>>
>> no one has picked this.
>> http://lists.freedesktop.org/archives/dri-devel/2014-May/059189.html
>>
>> Even Alex ACKed it.
>> http://lists.freedesktop.org/archives/dri-de
On 19 May 2014 15:13, David Herrmann wrote:
> Hi
>
> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood wrote:
>> Signed-off-by: Thomas Wood
>
> The commit-msg lacks any discussion why this change is done. What is
> the reason to do that? Isn't the kernel-command-line enough? Why is
> this a regular f
Hi
On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> On 19 May 2014 15:13, David Herrmann wrote:
>> Hi
>>
>> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood
>> wrote:
>>> Signed-off-by: Thomas Wood
>>
>> The commit-msg lacks any discussion why this change is done. What is
>> the reason to do
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
> op 19-05-14 15:42, Thomas Hellstrom schreef:
>> Hi, Maarten!
>>
>> Some nitpicks, and that krealloc within rcu lock still worries me.
>> Otherwise looks good.
>>
>> /Thomas
>>
>>
>>
>> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
>>> @@ -55,8 +
On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
> Hi
>
> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood wrote:
> > On 19 May 2014 15:13, David Herrmann wrote:
> >> Hi
> >>
> >> On Mon, May 19, 2014 at 3:37 PM, Thomas Wood
> >> wrote:
> >>> Signed-off-by: Thomas Wood
> >>
> >> Th
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/4e3affc6/attachment-0001.html>
ri-devel/attachments/20140519/cef35873/attachment.html>
On Fri, May 16, 2014 at 5:36 AM, Rafa? Mi?ecki wrote:
> DCE 3.1 and 3.2 should be programmed in a different way than DCE 2 and
> DCE 3. The order of setting registers and sets of registers are
> different.
> It's still unsure how we will handle DCE 3.1 vs. DCE 3.2, since they
> have few difference
I've pushed my latest working branches to gitorious[0]. staging/work is
the branch that has everything.
Thierry
[0]: https://gitorious.org/thierryreding/linux
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Si
e.
Thierry
[0]: https://lkml.org/lkml/2013/10/7/188
-- 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/20140519/ae2f37b2/attachment.sig>
Hi
On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter wrote:
> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood
>> wrote:
>> > It was intended as a debug/testing feature to allow tests in
>> > intel-gpu-tools to enable or disable connec
1 - 100 of 125 matches
Mail list logo
