On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
> wrote:
> > On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
> >>
> >> From: Jerome Glisse
> >>
> >> This patch add a minimum residency time configurable for each memory
> >> pool (VR
On 11/26/2012 09:19 PM, Terje Bergström wrote:
> Add client driver for 2D device.
>
> Signed-off-by: Arto Merilainen
> Signed-off-by: Terje Bergstrom
>
> ---
>
[...]
> +
> +static int
> +tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
> + struct drm_file
Op 28-11-12 20:21, Thomas Hellstrom schreef:
> On 11/28/2012 07:32 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 16:10, Thomas Hellstrom schreef:
>>> On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
Op 28-11-12 15:23, Thomas Hellstrom schreef:
> On 11/28/2012 02:55 PM, Maarten Lankhorst wrot
On 11/28/2012 09:09 PM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
>> From: Jerome Glisse
>>
>> It make no sense to preserve caching state especialy when
>> moving from vram to system. It burden the page allocator to
>> match the vram caching (often WC) which just burn CPU c
I think the problem with Radeon/TTM is much deeper. Let me demonstrate
it on the following example.
Unigine Heaven needs about 385MB of space for static resources, that's
only 75% of my 512MB card. Yet, TTM is not capable of getting all of
that into VRAM. If I allow GTT placements, I get 20 fps, w
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121128/b37985d1/attachment.html>
delayed_work powerstate_down;/* Power state management */
> + int num_clks; /* Number of clocks opened for dev */
> + struct clk *clk[NVHOST_MODULE_MAX_CLOCKS];
> + struct mutexlock; /* Power management lock */
> + int powerstate; /* Current power state */
> + int refcount; /* Number of tasks active */
> + wait_queue_head_t idle_wq; /* Work queue for idle */
> +
> + struct nvhost_channel *channel; /* Channel assigned for the module */
> + struct kobject *power_kobj; /* kobj to hold power sysfs entries */
> + struct nvhost_device_power_attr *power_attrib; /* sysfs attributes */
> + struct dentry *debugfs; /* debugfs directory */
> +
> + void *private_data; /* private platform data */
> + struct platform_device *pdev; /* owner platform_device */
> +
> + /* Finalize power on. Can be used for context restore. */
> + void (*finalize_poweron)(struct platform_device *dev);
> +
> + /* Device is busy. */
> + void (*busy)(struct platform_device *);
> +
> + /* Device is idle. */
> + void (*idle)(struct platform_device *);
> +
> + /* Device is going to be suspended */
> + void (*suspend_ndev)(struct platform_device *);
> +
> + /* Device is initialized */
> + void (*init)(struct platform_device *dev);
> +
> + /* Device is de-initialized. */
> + void (*deinit)(struct platform_device *dev);
> +
> + /* Preparing for power off. Used for context save. */
> + int (*prepare_poweroff)(struct platform_device *dev);
> +
> + /* Clock gating callbacks */
> + int (*prepare_clockoff)(struct platform_device *dev);
> + void (*finalize_clockon)(struct platform_device *dev);
> +};
A lot of this can be removed if you use existing infrastructure and
simplify the design a bit. Most of it can probably move into the main
struct host1x to avoid needless indirections that make the code hard to
follow and maintain.
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/20121128/704f1d2c/attachment-0001.pgp>
On 11/28/2012 02:33 PM, Lucas Stach wrote:
> Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergstr?m:
>> On 28.11.2012 01:00, Dave Airlie wrote:
>>> We generally aim for the first, to stop the gpu from reading/writing
>>> any memory it hasn't been granted access to,
>>> the second is nice
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Signed-off-by: Thierry Reding
Acked-by: Stephen Warren
---
Changes in v3:
- add linux-tegra mailing list
Changes in v2:
- insert entry in alphabetical order
- fix reference to driver directory
- fix reference to git tree
MAINTAINERS
On Thu, Nov 1, 2012 at 11:45 PM, Daniel Vetter
wrote:
> Again only minimal changes to make kerneldoc no longer shout. Plus a
> little introduction in the form of a inline DOC: section to quickly
> explain what this is all about.
Did someone build these?
> diff --git a/drivers/gpu/drm/drm_fb_hel
tion/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121128/6de0c020/attachment.pgp>
On 11/28/2012 07:32 PM, Maarten Lankhorst wrote:
> Op 28-11-12 16:10, Thomas Hellstrom schreef:
>> On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
>>> Op 28-11-12 15:23, Thomas Hellstrom schreef:
On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
> Op 28-11-12 14:21, Thomas Hellstrom schree
l these fixed.
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/20121128/45829511/attachment.pgp>
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Signed-off-by: Thierry Reding
---
Changes in v2:
- insert entry in alphabetical order
- fix reference to driver directory
- fix reference to git tree
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 17:13, Lucas Stach wrote:
> > To be honest I still don't grok all of this, but nonetheless I try my
> > best.
>
> Sorry. I promised in another thread a write-up explaining the design. I
> still owe you guys that.
>
Op 28-11-12 16:10, Thomas Hellstrom schreef:
> On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 15:23, Thomas Hellstrom schreef:
>>> On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
Op 28-11-12 14:21, Thomas Hellstrom schreef:
> On 11/28/2012 01:15 PM, Maarten Lankhorst wrot
On Wed, Nov 28, 2012 at 6:44 PM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a mi
On Wed, Nov 28, 2012 at 6:13 PM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom
> wrote:
>> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>>
>>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
From: Jerome Glisse
It make no sense to preserve caching stat
On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
wrote:
> On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> This patch add a minimum residency time configurable for each memory
>> pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
>> eviction
On 28.11.2012 17:13, Lucas Stach wrote:
> To be honest I still don't grok all of this, but nonetheless I try my
> best.
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
> Anyway, shouldn't nvhost be something like an allocator used by host1x
> clien
On Wed, Nov 28, 2012 at 4:51 PM, Marek Ol??k wrote:
> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> it on the following example.
>
> Unigine Heaven needs about 385MB of space for static resources, that's
> only 75% of my 512MB card. Yet, TTM is not capable of getting all
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a mini
On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom
wrote:
> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>
>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> It make no sense to preserve caching state especialy when
>>> moving from vram to system. It burden the pag
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121128/0f6f66e7/attachment.html>
On 28.11.2012 16:06, Lucas Stach wrote:
> Why do even need/use dma-buf for this use case? This is all one DRM
> device, even if we separate host1x and gr2d as implementation modules.
I didn't want to implement dependency to drm gem objects in nvhost, but
we have thought about doing that. dma-buf b
Am Mittwoch, den 28.11.2012, 16:45 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 16:06, Lucas Stach wrote:
> > Why do even need/use dma-buf for this use case? This is all one DRM
> > device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency t
On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom wrote:
> > On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
> >>
> >> From: Jerome Glisse
> >>
> >> This patch add a minimum residency time configurable for each memory
> >> pool (VRAM, GT
On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
> Op 28-11-12 15:23, Thomas Hellstrom schreef:
>> On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
>>> Op 28-11-12 14:21, Thomas Hellstrom schreef:
On 11/28/2012 01:15 PM, Maarten Lankhorst wrote:
> Op 28-11-12 12:54, Thomas Hellstrom schree
On Wed, Nov 28, 2012 at 6:44 PM, Alan Swanson wrote:
> On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
>> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom
>> wrote:
>> > On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a minim
On 28.11.2012 15:33, Lucas Stach wrote:
> So this is obviously wrong. Userspace has to allocate a pushbuffer from
> the kernel just as every other buffer, then map it into it's own address
> space to push in commands. At submit time of the pushbuf kernel has to
> make sure that userspace is not abl
From: Jerome Glisse
Force the use of cached memory when evicting from vram on non agp
hardware. Also force write combine on agp hw. This is to insure
the minimum cache type change when allocating memory and improving
memory eviction especialy on pci/pcie hw.
Signed-off-by: Jerome Glisse
---
dr
Op 28-11-12 15:23, Thomas Hellstrom schreef:
> On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 14:21, Thomas Hellstrom schreef:
>>> On 11/28/2012 01:15 PM, Maarten Lankhorst wrote:
Op 28-11-12 12:54, Thomas Hellstrom schreef:
> On 11/28/2012 12:25 PM, Maarten Lankhorst wrot
On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
> Replace the while loop with a simple for each loop, and only run the
> delayed destroy cleanup if we can reserve the buffer first.
>
> No race occurs, since lru lock is never dropped any more. An empty list
> and a list full of unreservable buffers
On Wed, Nov 28, 2012 at 6:13 PM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom wrote:
>> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>>
>>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
From: Jerome Glisse
It make no sense to preserve caching state e
On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom wrote:
> On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> This patch add a minimum residency time configurable for each memory
>> pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
>> eviction from
On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
> Op 28-11-12 14:21, Thomas Hellstrom schreef:
>> On 11/28/2012 01:15 PM, Maarten Lankhorst wrote:
>>> Op 28-11-12 12:54, Thomas Hellstrom schreef:
On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
> By removing the unlocking of lru and retak
On Wed, Nov 28, 2012 at 4:51 PM, Marek Olšák wrote:
> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> it on the following example.
>
> Unigine Heaven needs about 385MB of space for static resources, that's
> only 75% of my 512MB card. Yet, TTM is not capable of getting all
On 11/28/2012 04:58 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse
This patch add a minimum residency time configurable for each memory
pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
eviction from VRAM up to a point where the GPU pretty much spend all
it's time moving th
On 28.11.2012 01:00, Dave Airlie wrote:
> We generally aim for the first, to stop the gpu from reading/writing
> any memory it hasn't been granted access to,
> the second is nice to have though, but really requires a GPU with VM
> to implement properly.
I wonder if we should aim at root only acce
On Wed, Nov 28, 2012 at 5:18 PM, Thomas Hellstrom wrote:
> On 11/28/2012 09:09 PM, Jerome Glisse wrote:
>>
>> On Wed, Nov 28, 2012 at 10:05 AM, wrote:
>>>
>>> From: Jerome Glisse
>>>
>>> It make no sense to preserve caching state especialy when
>>> moving from vram to system. It burden the page
On Wed, Nov 28, 2012 at 10:05 AM, wrote:
> From: Jerome Glisse
>
> It make no sense to preserve caching state especialy when
> moving from vram to system. It burden the page allocator to
> match the vram caching (often WC) which just burn CPU cycle
> for no good reasons.
>
> Signed-off-by: Jerom
Am Mittwoch, den 28.11.2012, 15:57 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 15:33, Lucas Stach wrote:
> > So this is obviously wrong. Userspace has to allocate a pushbuffer from
> > the kernel just as every other buffer, then map it into it's own address
> > space to push in commands. At subm
Op 28-11-12 14:21, Thomas Hellstrom schreef:
> On 11/28/2012 01:15 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 12:54, Thomas Hellstrom schreef:
>>> On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
By removing the unlocking of lru and retaking it immediately, a race is
removed where the bo
On 11/28/2012 05:39 AM, Stephen Warren wrote:
> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
> Instead of using the stride derived from the display
https://bugs.freedesktop.org/show_bug.cgi?id=57670
Priority: medium
Bug ID: 57670
Assignee: dri-devel@lists.freedesktop.org
Summary: segfault with etqw.demo
Severity: normal
Classification: Unclassified
OS: Linux (All)
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 01:00, Dave Airlie wrote:
> > We generally aim for the first, to stop the gpu from reading/writing
> > any memory it hasn't been granted access to,
> > the second is nice to have though, but really requires a GPU wit
/archives/dri-devel/attachments/20121128/a63a0aef/attachment-0001.html>
Op 28-11-12 20:21, Thomas Hellstrom schreef:
> On 11/28/2012 07:32 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 16:10, Thomas Hellstrom schreef:
>>> On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
Op 28-11-12 15:23, Thomas Hellstrom schreef:
> On 11/28/2012 02:55 PM, Maarten Lankhorst wrot
On 11/28/2012 01:15 PM, Maarten Lankhorst wrote:
> Op 28-11-12 12:54, Thomas Hellstrom schreef:
>> On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
>>> By removing the unlocking of lru and retaking it immediately, a race is
>>> removed where the bo is taken off the swap list or the lru list between
On 11/28/2012 09:09 PM, Jerome Glisse wrote:
On Wed, Nov 28, 2012 at 10:05 AM, wrote:
From: Jerome Glisse
It make no sense to preserve caching state especialy when
moving from vram to system. It burden the page allocator to
match the vram caching (often WC) which just burn CPU cycle
for no g
I think the problem with Radeon/TTM is much deeper. Let me demonstrate
it on the following example.
Unigine Heaven needs about 385MB of space for static resources, that's
only 75% of my 512MB card. Yet, TTM is not capable of getting all of
that into VRAM. If I allow GTT placements, I get 20 fps, w
From: Jerome Glisse
Force the use of cached memory when evicting from vram on non agp
hardware. Also force write combine on agp hw. This is to insure
the minimum cache type change when allocating memory and improving
memory eviction especialy on pci/pcie hw.
Signed-off-by: Jerome Glisse
---
dr
Op 28-11-12 12:54, Thomas Hellstrom schreef:
>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 112
>> +++
>> 1 file changed, 60 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm
On Mon, Nov 26, 2012 at 03:19:07PM +0200, Terje Bergstrom wrote:
[...]
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index fb9a14e..94c861b 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2463,4 +2463,6 @@ config FB_SH_MOBILE_MERAM
> Up to 4 memory
Op 28-11-12 12:54, Thomas Hellstrom schreef:
> On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
>> By removing the unlocking of lru and retaking it immediately, a race is
>> removed where the bo is taken off the swap list or the lru list between
>> the unlock and relock. As such the cleanup_refs co
From: Jerome Glisse
This patch add a minimum residency time configurable for each memory
pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
eviction from VRAM up to a point where the GPU pretty much spend all
it's time moving things in and out.
Signed-off-by: Jerome Glisse
---
So i spend the day looking at ttm and eviction. The first patch i sent
earlier is i believe something that should be merged. This patch however
is more about discussing if other people are interested in similar mecanism
to be share among driver through ttm. I could otherwise just move its logic
to
On 11/28/2012 02:33 PM, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergström:
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have thou
On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
> By removing the unlocking of lru and retaking it immediately, a race is
> removed where the bo is taken off the swap list or the lru list between
> the unlock and relock. As such the cleanup_refs code can be simplified,
> it will attempt to call tt
On 11/28/2012 12:25 PM, Maarten Lankhorst wrote:
> This requires changing the order in ttm_bo_cleanup_refs_or_queue to
> take the reservation first, as there is otherwise no race free way to
> take lru lock before fence_lock.
>
> Signed-off-by: Maarten Lankhorst
Technically I think it would be po
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
All items on the lru list are always reservable, so this is a stupid
thing to keep. Not only that, it is used in a way which would
guarantee deadlocks if it were ever to be set to block on reserve.
This is a lot of churn, but mostly because of the removal of the
argument which can be nested arbitr
Replace the goto loop with a simple for each loop, and only run the
delayed destroy cleanup if we can reserve the buffer first.
No race occurs, since lru lock is never dropped any more. An empty list
and a list full of unreservable buffers both cause -EBUSY to be returned,
which is identical to th
Replace the while loop with a simple for each loop, and only run the
delayed destroy cleanup if we can reserve the buffer first.
No race occurs, since lru lock is never dropped any more. An empty list
and a list full of unreservable buffers both cause -EBUSY to be returned,
which is identical to t
By removing the unlocking of lru and retaking it immediately, a race is
removed where the bo is taken off the swap list or the lru list between
the unlock and relock. As such the cleanup_refs code can be simplified,
it will attempt to call ttm_bo_wait non-blockingly, and if it fails
it will drop th
The few places that care should have those checks instead.
This allows destruction of bo backed memory without a reservation.
It's required for being able to rework the delayed destroy path,
as it is no longer guaranteed to hold a reservation before unlocking.
However any previous wait is still gu
This requires changing the order in ttm_bo_cleanup_refs_or_queue to
take the reservation first, as there is otherwise no race free way to
take lru lock before fence_lock.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 31 +++
drivers/gpu
On 11/28/2012 12:18 PM, Thierry Reding wrote:
> Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Aside from one comment below,
Acked-by: Stephen Warren
> +L: dri-devel at lists.freedesktop.org
Should linux-tegra at vger.kernel.org also be CC'd so that everything
Tegra-related goe
On Wed, Nov 28, 2012 at 10:05 AM, wrote:
> From: Jerome Glisse
>
> It make no sense to preserve caching state especialy when
> moving from vram to system. It burden the page allocator to
> match the vram caching (often WC) which just burn CPU cycle
> for no good reasons.
>
> Signed-off-by: Jerom
From: Jerome Glisse
It make no sense to preserve caching state especialy when
moving from vram to system. It burden the page allocator to
match the vram caching (often WC) which just burn CPU cycle
for no good reasons.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++-
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Signed-off-by: Thierry Reding
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f503405..27c89b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2504,6 +2504,14 @@ S: Suppo
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Signed-off-by: Thierry Reding
Acked-by: Stephen Warren
---
Changes in v3:
- add linux-tegra mailing list
Changes in v2:
- insert entry in alphabetical order
- fix reference to driver directory
- fix reference to git tree
MAINTAINERS
On Wed, Nov 28, 2012 at 12:22:31PM -0700, Stephen Warren wrote:
> On 11/28/2012 12:18 PM, Thierry Reding wrote:
> > Add myself as the maintainer of the NVIDIA Tegra DRM driver.
>
> Aside from one comment below,
>
> Acked-by: Stephen Warren
>
> > +L: dri-devel@lists.freedesktop.org
>
> Should l
This patch adds support for controlling power of hdmi phy for
exynos5 soc. A special bit is provided in exynos5 for directly
switching of PHY while in exynos4, phy power needs to be controlled
through i2c settings. I2C configuration may affect the suspend to
resume and wake-up time requirements hen
This patch adds support for runtime power management for
drm mixer driver.
Signed-off-by: Rahul Sharma
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_mixer.c | 65 +
1 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exy
This patch adds runtime power management support for exynos drm
hdmi driver.
Signed-off-by: Rahul Sharma
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 60 +
1 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/e
This patch set adds support for runtime power management for hdmi and
mixer devices. Its also adds support for hdmiphy power control.
It has been tested for hot plugin-plugout and dpms scenarios.
Based on exynos-drm-next branch of
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
On 27.11.2012 19:07, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> There is a rare case, that seems to only happen accross suspend/resume
> cycle, where a bo is associated with several different handle. This
> lead to a deadlock in ttm buffer reservation path. This could only
> happen wit
On 11/28/2012 12:18 PM, Thierry Reding wrote:
> Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Aside from one comment below,
Acked-by: Stephen Warren
> +L: dri-devel@lists.freedesktop.org
Should linux-te...@vger.kernel.org also be CC'd so that everything
Tegra-related goes to o
On 11/28/2012 07:32 PM, Maarten Lankhorst wrote:
Op 28-11-12 16:10, Thomas Hellstrom schreef:
On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
Op 28-11-12 15:23, Thomas Hellstrom schreef:
On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
Op 28-11-12 14:21, Thomas Hellstrom schreef:
On 11/28/2
On Wed, Nov 28, 2012 at 07:57:53AM -0800, Joe Perches wrote:
> On Wed, 2012-11-28 at 12:10 +0100, Thierry Reding wrote:
> > Add myself as the maintainer of the NVIDIA Tegra DRM driver.
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > @@ -2504,6 +2504,14 @@ S: Supported
> > F: drivers/gpu/d
Add myself as the maintainer of the NVIDIA Tegra DRM driver.
Signed-off-by: Thierry Reding
---
Changes in v2:
- insert entry in alphabetical order
- fix reference to driver directory
- fix reference to git tree
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS
On 27.11.2012 20:02, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> To avoid kernel rejecting cs if we return different global name
> for same bo keep track of global name and always return the same.
> Seems to fix issue with suspend/resume failing and repeatly printing
> following message
From: Jerome Glisse
This patch add a minimum residency time configurable for each memory
pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
eviction from VRAM up to a point where the GPU pretty much spend all
it's time moving things in and out.
Signed-off-by: Jerome Glisse
---
So i spend the day looking at ttm and eviction. The first patch i sent
earlier is i believe something that should be merged. This patch however
is more about discussing if other people are interested in similar mecanism
to be share among driver through ttm. I could otherwise just move its logic
to
Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
> On 28.11.2012 17:13, Lucas Stach wrote:
> > To be honest I still don't grok all of this, but nonetheless I try my
> > best.
>
> Sorry. I promised in another thread a write-up explaining the design. I
> still owe you guys that.
>
On Wed, Nov 28, 2012 at 11:27:27AM +0100, Christian K?nig wrote:
> On 27.11.2012 19:07, j.glisse at gmail.com wrote:
> >From: Jerome Glisse
> >
> >There is a rare case, that seems to only happen accross suspend/resume
> >cycle, where a bo is associated with several different handle. This
> >lead t
Op 28-11-12 16:10, Thomas Hellstrom schreef:
> On 11/28/2012 03:46 PM, Maarten Lankhorst wrote:
>> Op 28-11-12 15:23, Thomas Hellstrom schreef:
>>> On 11/28/2012 02:55 PM, Maarten Lankhorst wrote:
Op 28-11-12 14:21, Thomas Hellstrom schreef:
> On 11/28/2012 01:15 PM, Maarten Lankhorst wrot
From: Jerome Glisse
It make no sense to preserve caching state especialy when
moving from vram to system. It burden the page allocator to
match the vram caching (often WC) which just burn CPU cycle
for no good reasons.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++-
On 11/28/2012 07:45 AM, Terje Bergstr?m wrote:
> On 28.11.2012 16:06, Lucas Stach wrote:
>> Why do even need/use dma-buf for this use case? This is all one DRM
>> device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency to drm gem objects in
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #44 from Alexandre Demers ---
Could this new commit 0980633afd9c7eecc0c75ef3bea4d3c6b7aa1898 help
(drm/radeon: track global bo name and always return the same)?
--
You are receiving this mail because:
You are the assignee for the bu
On Tue, Nov 27, 2012 at 9:31 PM, Terje Bergstr?m
wrote:
> On 27.11.2012 12:37, Thierry Reding wrote:
>> But in that case it should be made mandatory at first until proper IOMMU
>> support is enabled on Tegra30. Then it can be checked at driver probe
>> time whether or not to enable the extra chec
On 11/28/2012 07:45 AM, Terje Bergström wrote:
> On 28.11.2012 16:06, Lucas Stach wrote:
>> Why do even need/use dma-buf for this use case? This is all one DRM
>> device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency to drm gem objects in
On 28.11.2012 17:13, Lucas Stach wrote:
> To be honest I still don't grok all of this, but nonetheless I try my
> best.
Sorry. I promised in another thread a write-up explaining the design. I
still owe you guys that.
> Anyway, shouldn't nvhost be something like an allocator used by host1x
> clien
On Wed, 2012-11-28 at 12:10 +0100, Thierry Reding wrote:
> Add myself as the maintainer of the NVIDIA Tegra DRM driver.
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -2504,6 +2504,14 @@ S: Supported
> F: drivers/gpu/drm/exynos
> F: include/drm/exynos*
>
> +NVIDIA TEGRA DRM DRIVER
A
On Wed, 2012-11-28 at 12:10 +0100, Thierry Reding wrote:
> Add myself as the maintainer of the NVIDIA Tegra DRM driver.
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -2504,6 +2504,14 @@ S: Supported
> F: drivers/gpu/drm/exynos
> F: include/drm/exynos*
>
> +NVIDIA TEGRA DRM DRIVER
A
On Wed, Nov 28, 2012 at 11:27:27AM +0100, Christian König wrote:
> On 27.11.2012 19:07, j.gli...@gmail.com wrote:
> >From: Jerome Glisse
> >
> >There is a rare case, that seems to only happen accross suspend/resume
> >cycle, where a bo is associated with several different handle. This
> >lead to a
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/20121128/100a576d/attachment.html>
Am Mittwoch, den 28.11.2012, 16:45 +0200 schrieb Terje Bergström:
> On 28.11.2012 16:06, Lucas Stach wrote:
> > Why do even need/use dma-buf for this use case? This is all one DRM
> > device, even if we separate host1x and gr2d as implementation modules.
>
> I didn't want to implement dependency t
1 - 100 of 137 matches
Mail list logo
