why glxinfo, eglinfo and es2_info crash the gpu or at least
disable subsequent invocations of anything accelerated.
--
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/3a22d03f/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/5224c2c6/attachment.html>
panel
> > power up sequence diagram that doesn't mean we have to implement it as
> > part of the panel driver.
> That is not "some spec". I believe all the AUO panels share the same
> sequence!
Just because some specs mention the backlight enable pin in some panel
power up sequence diagram that doesn't mean we have to implement it as
part of the panel driver.
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/2692ab97/attachment.sig>
Ravier ---
My laptop is dead, I can not test this anymore.
--
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/e9d57
On Mon, May 19, 2014 at 6:22 PM, David Herrmann
wrote:
>
> 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 al
When the PX card is off don't try and access it. Avoid hw access
to the card while it's off (e.g., reading back invalid temperature).
v2: be less strict
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/r
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
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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/65b61cbb/attachment.html>
|--- |FIXED
--
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/c937fbd3/attachment.html>
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
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
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
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
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
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
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
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/0b903d74/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/8cf2f420/attachment-0001.html>
ves/dri-devel/attachments/20140519/9816a249/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/9326efd7/attachment.html>
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>
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
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them. Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.
Reviewed-by: Daniel Vetter
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crt
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
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 the universal plane interface.
v2:
- Allow planes to be disabled w
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 to share that framebuffer creation with the
drm_mode_addfb2 ioctl ha
(respinning the whole patch series to pull the entire set back together now
that a couple patches have been added at the beginning)
Cursor planes are a bit trickier to support via the universal plane interface
than primary planes were. Legacy cursor ioctls take handles to driver buffers
directly
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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 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
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
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_CURSOR_BO)
> > + drm_mode_rmfb(dev, &fb->base.id, file_priv);
> > + retur
ri-devel/attachments/20140519/cef35873/attachment.html>
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> From: Thierry Reding
>
> Add the GK20A device node to Tegra124's device tree.
At a quick glance, patches 3-5 look fine too. I'll hold off on applying
them until patches 1-2 have been applied to the DRM/... tree.
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/4e3affc6/attachment-0001.html>
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> Add the device tree binding documentation for the GK20A GPU used in
> Tegra K1 SoCs.
A few minor nits, but otherwise,
Acked-by: Stephen Warren
> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
> b/Documentation/devicetree/bi
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
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
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
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
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
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=75921
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=75931
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
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=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
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/4ad3ceb5/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/e7b2c590/attachment.html>
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
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
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
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,
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
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
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
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
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
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
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
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_
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
https://bugzilla.kernel.org/show_bug.cgi?id=74551
Alan changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You are receiving this mail because:
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,
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.
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 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
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
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:
>>>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/a1b29995/attachment.html>
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>
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
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: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
On Mon, Feb 24, 2014 at 8:29 AM, Maarten Lankhorst
wrote:
> Just to show it's easy.
>
> Android syncpoints can be mapped to a timeline. This removes the need
> to maintain a separate api for synchronization. I've left the android
> trace events in place, but the core fence events should already be
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=75301
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
--
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>
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>
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
1 - 100 of 125 matches
Mail list logo
