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 from VRAM up to a point where the GPU pretty much spend all
> it's ti
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.glisse at gmail.com wrote:
>> >>
>> >> From: Jerome Glisse
>> >>
>> >> This patch add a m
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
On 11/29/2012 03:15 AM, Marek Ol??k wrote:
> 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.glisse at gmail.com wrote:
> From: Jer
Fixed build warning as below:
drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
drivers/gpu/drm/drm_pci.c:496:9: warning: 'lnkcap' may be used uninitialized in
this function [-Wuninitialized]
drivers/gpu/drm/drm_pci.c:497:10: warning: 'lnkcap2' may be used uninitialized
in th
On 28.11.2012 20:46, Lucas Stach wrote:
> Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
>> Sorry. I promised in another thread a write-up explaining the design. I
>> still owe you guys that.
> That would be really nice to have. I'm also particularly interested in
> how you plan
On 11/29/2012 12:24 AM, 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 (VRAM, GTT, ...). Intent
t nvhost_syncpt *sp,
> + u32 id, u32 thresh)
> +{
> + return nvhost_syncpt_wait_timeout(sp, id, thresh,
> + MAX_SCHEDULE_TIMEOUT, NULL);
> +}
> +
> void nvhost_syncpt_debug(struct nvhost_syncpt *sp);
>
> static inline int nvhost_syncpt_is_valid(struct nvhost_syncpt *sp, u32 id)
> diff --git a/include/linux/nvhost.h b/include/linux/nvhost.h
> index 20ba2a5..745f31c 100644
> --- a/include/linux/nvhost.h
> +++ b/include/linux/nvhost.h
> @@ -35,6 +35,7 @@ struct nvhost_device_power_attr;
> #define NVHOST_DEFAULT_CLOCKGATE_DELAY .clockgate_delay = 25
> #define NVHOST_NAME_SIZE 24
> #define NVSYNCPT_INVALID (-1)
> +#define NVHOST_NO_TIMEOUT(-1)
Couldn't you reuse MAX_SCHEDULE_TIMEOUT instead? You already use it as
the value for the timeout parameter in nvhost_syncpt_wait().
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/20121129/d39cf871/attachment.pgp>
Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergstr?m:
> On 28.11.2012 20:46, Lucas Stach wrote:
> > Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergstr?m:
> >> Sorry. I promised in another thread a write-up explaining the design. I
> >> still owe you guys that.
> > That wou
On 11/26/2012 09:19 PM, Terje Bergstr?m wrote:
> Add nvhost, the driver for host1x. This patch adds support for reading and
> incrementing sync points and dynamic power management.
>
> Signed-off-by: Terje Bergstrom
>
> ---
> drivers/video/Kconfig |2 +
> driver
On 11/28/2012 10: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 of
> that
On Don, 2012-11-29 at 10:18 +0100, Thomas Hellstrom wrote:
> On 11/28/2012 10: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
> > onl
On 11/29/2012 10:28 AM, Michel D?nzer wrote:
> On Don, 2012-11-29 at 10:18 +0100, Thomas Hellstrom wrote:
>> On 11/28/2012 10: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 385M
On 11/28/2012 11:26 PM, Maarten Lankhorst wrote:
> 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 schree
On 11/26/2012 09:19 PM, Terje Bergstr?m wrote:
> Add support for host1x client modules, and host1x channels to submit
> work to the clients. The work is submitted in dmabuf buffers, so add
> support for dmabuf memory management, too.
[...]
> diff --git a/drivers/video/tegra/host/bus_client.c
> b/
ter a client with host1x which would
already initialize the appropriate fields. There can be other, separate
functions for resource allocations such as syncpoints and channels,
though.
> +int nvhost_client_device_suspend(struct platform_device *dev);
Again, I think this should be handled via runtime PM.
> +struct nvhost_channel *nvhost_getchannel(struct nvhost_channel *ch);
> +void nvhost_putchannel(struct nvhost_channel *ch);
These are oddly named. Better names would be nvhost_channel_get() or
nvhost_channel_put().
> +int nvhost_channel_submit(struct nvhost_job *job);
> +
> +enum host1x_class {
> + NV_HOST1X_CLASS_ID = 0x1,
> + NV_GRAPHICS_2D_CLASS_ID = 0x51,
> +};
Maybe this enumeration should be made more consistent, somewhat along
the lines of:
enum host1x_class {
HOST1X_CLASS_HOST1X = 0x01,
HOST1X_CLASS_2D = 0x51,
};
Again, I'll need more time to go over the rest of the code but the good
news is that I'm starting to form a better picture of how things work.
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/20121129/2b04c555/attachment.pgp>
Hi Linus
just driver fixes, nothing major, except maybe ilk rc6 disable.
intel: revert ironlake rc6 - we still have one ilk regression, but this
gets rid of one big one, turn off cloning, and a directed fix for Apple
edp
radeon: one modesetting fix
exynos: minor fixes
Dave.
The following cha
Hi Dave,
Besides the big item of lifting the "preliminary hw support" tag from the
Haswell code, just small bits&pieces all over:
- Leftover Haswell patches and some fixes from Paulo
- LyncPoint PCH support (for hsw)
- OOM handling improvements from Chris Wilson
- connector property and send_vblan
On 28.11.2012 23:23, Thierry Reding wrote:
> This could be problematic. Since drivers/video and drivers/gpu/drm are
> separate trees, this would entail a continuous burden on keeping both
> trees synchronized. While I realize that eventually it might be better
> to put the host1x driver in a separa
On Thu, Nov 29, 2012 at 11:12:00AM +0100, Daniel Vetter wrote:
> Besides the big item of lifting the "preliminary hw support" tag from the
> Haswell code, just small bits&pieces all over:
> - Leftover Haswell patches and some fixes from Paulo
> - LyncPoint PCH support (for hsw)
> - OOM handling imp
On 29.11.2012 10:44, Thierry Reding wrote:
>> diff --git a/drivers/video/tegra/host/dev.c b/drivers/video/tegra/host/dev.c
>> index 98c9c9f..025a820 100644
>> --- a/drivers/video/tegra/host/dev.c
>> +++ b/drivers/video/tegra/host/dev.c
>> @@ -43,6 +43,13 @@ u32 host1x_syncpt_read(u32 id)
>> }
>>
On 29.11.2012 12:01, Mark Zhang wrote:
>> +fail:
>> +/* Add clean-up */
>
> Yes, add "nvhost_module_deinit" here?
Sounds good.
>> +int nvhost_client_device_suspend(struct platform_device *dev)
>> +{
>> +int ret = 0;
>> +struct nvhost_device_data *pdata = platform_get_drvdata(dev);
>>
On 29.11.2012 12:04, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Nov 26, 2012 at 03:19:09PM +0200, Terje Bergstrom wrote:
>
> I've skipped a lot of code here that I need more time to review.
Thanks already for the very good comments! It's great getting comments
on the code
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
; + 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.
>
> Actually, this struct is generic for host1x and host1x clients, so they
> cannot be moved to host1x. I do also realize that I'm not using them in
> the patch sets I sent for 2D.
I've said this before, and I think that this tries to be overly generic.
Display controllers for instance work quite well without an attached
nvhost_channel.
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/20121129/10e72d4f/attachment-0001.pgp>
Hi Dave,
This is second time pull request for -next and based on previous
pull request. For this, please refer to the below link,
http://permalink.gmane.org/gmane.comp.video.dri.devel/76834
And a summary to this is as the following:
- add sending AVI and AVI info frames.
. this adds some cod
me backing nvhost object. Note that I'm
> not sure how useful this would be, but it seems like a reasonable design
> to me being able to do so.
Wouldn't that be useful for sharing buffers between DRM and V4L2 using
dma-buf? I'm not very familiar with how exactly importing and exporting
work with dma-buf, so maybe I need to read up some more.
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/20121129/58500492/attachment.pgp>
On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
wrote:
> On 11/29/2012 03:15 AM, Marek Ol??k wrote:
>>
>> 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
wrot
On 29.11.2012 11:09, Lucas Stach wrote:
> We should aim for a clean split here. GEM handles are something which is
> really specific to how DRM works and as such should be constructed by
> tegradrm. nvhost should really just manage allocations/virtual address
> space and provide something that is a
On Thu, Nov 29, 2012 at 1:11 PM, Inki Dae wrote:
> - add sending AVI and AVI info frames.
> . this adds some codes for composing AVI and AUI info frames
> and send them every VSYNC for HDMI Certification.
Imo we have a few too many avi infoframe implementations in the drm
drivers already. I
On Thu, Nov 29, 2012 at 09:41:34AM +0100, Thomas Hellstrom wrote:
> On 11/29/2012 12:24 AM, 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 re
On 11/29/2012 03:21 AM, Terje Bergstr?m wrote:
> On 28.11.2012 23:23, Thierry Reding wrote:
...
>>> + regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>> + intr0 = platform_get_resource(dev, IORESOURCE_IRQ, 0);
>>> + intr1 = platform_get_resource(dev, IORESOURCE_IRQ, 1);
>>> +
>>>
On 11/29/2012 04:47 AM, Thierry Reding wrote:
> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m wrote:
>> On 28.11.2012 23:23, Thierry Reding wrote:
>>> This could be problematic. Since drivers/video and
>>> drivers/gpu/drm are separate trees, this would entail a
>>> continuous burden on
On 11/29/2012 01:44 AM, Thierry Reding wrote:
> On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote:
>> diff --git a/drivers/video/tegra/host/host1x/host1x_intr.c
>> b/drivers/video/tegra/host/host1x/host1x_intr.c
> [...]
>> +/* Spacing between sync registers */ +#define REGISTER_STRID
On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
wrote:
> On 11/28/2012 10: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
On Thu, Nov 29, 2012 at 08:20:17PM +0100, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
> wrote:
> > On 11/28/2012 10:51 PM, Marek Ol??k wrote:
> >>
> >> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> >> it on the following example.
> >>
> >> Un
From: Jerome Glisse
If GPU reset fails the gart table ptr might be NULL avoid a
kernel segfault in this rare event.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r600.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/
On 11/29/2012 01:52 PM, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
> wrote:
>> On 11/29/2012 03:15 AM, Marek Ol??k wrote:
>>> 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
So as a followup is 2 patch. The first one just stop trying to move
object at each cs ioctl i believe it could be included in 3.7 as it
improve performances (especialy with vram change from userspace).
The second one implement a vram eviction policy. It's a simple one,
buffer used for write operat
From: Jerome Glisse
The bo creation placement is where the bo will be. Instead of trying
to move bo at each command stream let this work to another worker
thread that will use more advance heuristic.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/dr
From: Jerome Glisse
Use delayed work thread to move buffer out of vram if they haven't
been use over some period of time. This allow to make room for
buffer that are actively use.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 13 ++
drivers/gpu/drm/radeon/radeon_cs
On 11/29/2012 08:20 PM, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
> wrote:
>> On 11/28/2012 10: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 385
On 11/29/2012 12:36 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 Thu, Nov 29, 2012 at 12:45:06PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> spinlock_t should always be used.
>
> LD drivers/gpu/drm/i915/built-in.o
> CHECK drivers/gpu/drm/i915/i915_drv.c
> CC [M] drivers/gpu/drm/i915/i915_drv.o
> CHECK drivers/gpu/drm/i
On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom
wrote:
> On 11/29/2012 01:52 PM, Marek Ol??k wrote:
>>
>> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/29/2012 03:15 AM, Marek Ol??k wrote:
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson
wrote:
>
>
From: "Luis R. Rodriguez"
Turns out a few drivers have strayed away from using the
spinlock_t typedef and decided to use struct spinlock
directly. This series converts these drivers to use
spinlock_t. Each change has been compile tested with
allmodconfig and sparse checked. Driver developers
may
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/gpu/drm/i915/built-in.o
CHECK drivers/gpu/drm/i915/i915_drv.c
CC [M] drivers/gpu/drm/i915/i915_drv.o
CHECK drivers/gpu/drm/i915/i915_dma.c
CC [M] drivers/gpu/drm/i915/i915_dma.o
CHECK drivers/gpu/drm/
On Thu, Nov 29, 2012 at 8:57 PM, Marek Ol??k wrote:
> On Thu, Nov 29, 2012 at 4:35 PM, wrote:
>> So as a followup is 2 patch. The first one just stop trying to move
>> object at each cs ioctl i believe it could be included in 3.7 as it
>> improve performances (especialy with vram change from use
On 11/29/2012 03:15 AM, Marek Olšák wrote:
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 patc
Fixed build warning as below:
drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
drivers/gpu/drm/drm_pci.c:496:9: warning: 'lnkcap' may be used uninitialized in
this function [-Wuninitialized]
drivers/gpu/drm/drm_pci.c:497:10: warning: 'lnkcap2' may be used uninitialized
in th
On 28.11.2012 20:46, Lucas Stach wrote:
> Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
>> Sorry. I promised in another thread a write-up explaining the design. I
>> still owe you guys that.
> That would be really nice to have. I'm also particularly interested in
> how you plan
On 11/29/2012 12:24 AM, 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, GTT, ...). Intention is to avoid having
On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote:
[...]
> diff --git a/drivers/video/tegra/host/chip_support.h
> b/drivers/video/tegra/host/chip_support.h
[...]
> +struct nvhost_intr_ops {
> + void (*init_host_sync)(struct nvhost_intr *);
> + void (*set_host_clocks_per_usec)
Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergström:
> On 28.11.2012 20:46, Lucas Stach wrote:
> > Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
> >> Sorry. I promised in another thread a write-up explaining the design. I
> >> still owe you guys that.
> > That wou
On 11/26/2012 09:19 PM, Terje Bergström wrote:
> Add nvhost, the driver for host1x. This patch adds support for reading and
> incrementing sync points and dynamic power management.
>
> Signed-off-by: Terje Bergstrom
>
> ---
> drivers/video/Kconfig |2 +
> driver
On 11/28/2012 10: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 of
that into VRA
On Don, 2012-11-29 at 10:18 +0100, Thomas Hellstrom wrote:
> On 11/28/2012 10: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
> > onl
On 11/29/2012 10:28 AM, Michel Dänzer wrote:
On Don, 2012-11-29 at 10:18 +0100, Thomas Hellstrom wrote:
On 11/28/2012 10: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 s
On 11/28/2012 11:26 PM, Maarten Lankhorst wrote:
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/2
On 11/26/2012 09:19 PM, Terje Bergström wrote:
> Add support for host1x client modules, and host1x channels to submit
> work to the clients. The work is submitted in dmabuf buffers, so add
> support for dmabuf memory management, too.
[...]
> diff --git a/drivers/video/tegra/host/bus_client.c
> b/
On Mon, Nov 26, 2012 at 03:19:09PM +0200, Terje Bergstrom wrote:
I've skipped a lot of code here that I need more time to review.
[...]
> diff --git a/drivers/video/tegra/host/nvhost_intr.c
> b/drivers/video/tegra/host/nvhost_intr.c
[...]
> +static void action_submit_complete(struct nvhost_waitl
Hi Linus
just driver fixes, nothing major, except maybe ilk rc6 disable.
intel: revert ironlake rc6 - we still have one ilk regression, but this
gets rid of one big one, turn off cloning, and a directed fix for Apple
edp
radeon: one modesetting fix
exynos: minor fixes
Dave.
The following cha
Hi Dave,
Besides the big item of lifting the "preliminary hw support" tag from the
Haswell code, just small bits&pieces all over:
- Leftover Haswell patches and some fixes from Paulo
- LyncPoint PCH support (for hsw)
- OOM handling improvements from Chris Wilson
- connector property and send_vblan
On 28.11.2012 23:23, Thierry Reding wrote:
> This could be problematic. Since drivers/video and drivers/gpu/drm are
> separate trees, this would entail a continuous burden on keeping both
> trees synchronized. While I realize that eventually it might be better
> to put the host1x driver in a separa
On Thu, Nov 29, 2012 at 11:12:00AM +0100, Daniel Vetter wrote:
> Besides the big item of lifting the "preliminary hw support" tag from the
> Haswell code, just small bits&pieces all over:
> - Leftover Haswell patches and some fixes from Paulo
> - LyncPoint PCH support (for hsw)
> - OOM handling imp
On 29.11.2012 10:44, Thierry Reding wrote:
>> diff --git a/drivers/video/tegra/host/dev.c b/drivers/video/tegra/host/dev.c
>> index 98c9c9f..025a820 100644
>> --- a/drivers/video/tegra/host/dev.c
>> +++ b/drivers/video/tegra/host/dev.c
>> @@ -43,6 +43,13 @@ u32 host1x_syncpt_read(u32 id)
>> }
>>
On 29.11.2012 12:01, Mark Zhang wrote:
>> +fail:
>> +/* Add clean-up */
>
> Yes, add "nvhost_module_deinit" here?
Sounds good.
>> +int nvhost_client_device_suspend(struct platform_device *dev)
>> +{
>> +int ret = 0;
>> +struct nvhost_device_data *pdata = platform_get_drvdata(dev);
>>
On 29.11.2012 12:04, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Nov 26, 2012 at 03:19:09PM +0200, Terje Bergstrom wrote:
>
> I've skipped a lot of code here that I need more time to review.
Thanks already for the very good comments! It's great getting comments
on the code
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
On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote:
> On 28.11.2012 23:23, Thierry Reding wrote:
> > This could be problematic. Since drivers/video and drivers/gpu/drm are
> > separate trees, this would entail a continuous burden on keeping both
> > trees synchronized. While I realize
Hi Dave,
This is second time pull request for -next and based on previous
pull request. For this, please refer to the below link,
http://permalink.gmane.org/gmane.comp.video.dri.devel/76834
And a summary to this is as the following:
- add sending AVI and AVI info frames.
. this adds some cod
On Thu, Nov 29, 2012 at 10:09:13AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.11.2012, 10:17 +0200 schrieb Terje Bergström:
> > On 28.11.2012 20:46, Lucas Stach wrote:
> > > Am Mittwoch, den 28.11.2012, 18:23 +0200 schrieb Terje Bergström:
> > >> Sorry. I promised in another thread a write-u
On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom wrote:
> On 11/29/2012 03:15 AM, Marek Olšák wrote:
>>
>> 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 29.11.2012 11:09, Lucas Stach wrote:
> We should aim for a clean split here. GEM handles are something which is
> really specific to how DRM works and as such should be constructed by
> tegradrm. nvhost should really just manage allocations/virtual address
> space and provide something that is a
On Thu, Nov 29, 2012 at 1:11 PM, Inki Dae wrote:
> - add sending AVI and AVI info frames.
> . this adds some codes for composing AVI and AUI info frames
> and send them every VSYNC for HDMI Certification.
Imo we have a few too many avi infoframe implementations in the drm
drivers already. I
On Thu, Nov 29, 2012 at 09:41:34AM +0100, Thomas Hellstrom wrote:
> On 11/29/2012 12:24 AM, 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 resid
On 11/29/2012 03:21 AM, Terje Bergström wrote:
> On 28.11.2012 23:23, Thierry Reding wrote:
...
>>> + regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>> + intr0 = platform_get_resource(dev, IORESOURCE_IRQ, 0);
>>> + intr1 = platform_get_resource(dev, IORESOURCE_IRQ, 1);
>>> +
>>>
On 11/29/2012 04:47 AM, Thierry Reding wrote:
> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergström wrote:
>> On 28.11.2012 23:23, Thierry Reding wrote:
>>> This could be problematic. Since drivers/video and
>>> drivers/gpu/drm are separate trees, this would entail a
>>> continuous burden on
On 11/29/2012 01:44 AM, Thierry Reding wrote:
> On Mon, Nov 26, 2012 at 03:19:08PM +0200, Terje Bergstrom wrote:
>> diff --git a/drivers/video/tegra/host/host1x/host1x_intr.c
>> b/drivers/video/tegra/host/host1x/host1x_intr.c
> [...]
>> +/* Spacing between sync registers */ +#define REGISTER_STRID
On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom wrote:
> On 11/28/2012 10: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 7
On Thu, Nov 29, 2012 at 08:20:17PM +0100, Marek Olšák wrote:
> On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom
> wrote:
> > On 11/28/2012 10:51 PM, Marek Olšák wrote:
> >>
> >> I think the problem with Radeon/TTM is much deeper. Let me demonstrate
> >> it on the following example.
> >>
> >> Un
From: Jerome Glisse
If GPU reset fails the gart table ptr might be NULL avoid a
kernel segfault in this rare event.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r600.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/
On 11/29/2012 01:52 PM, Marek Olšák wrote:
On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom wrote:
On 11/29/2012 03:15 AM, Marek Olšák wrote:
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, Thoma
So as a followup is 2 patch. The first one just stop trying to move
object at each cs ioctl i believe it could be included in 3.7 as it
improve performances (especialy with vram change from userspace).
The second one implement a vram eviction policy. It's a simple one,
buffer used for write operat
From: Jerome Glisse
The bo creation placement is where the bo will be. Instead of trying
to move bo at each command stream let this work to another worker
thread that will use more advance heuristic.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/dr
From: Jerome Glisse
Use delayed work thread to move buffer out of vram if they haven't
been use over some period of time. This allow to make room for
buffer that are actively use.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 13 ++
drivers/gpu/drm/radeon/radeon_cs
On 11/29/2012 08:20 PM, Marek Olšák wrote:
On Thu, Nov 29, 2012 at 10:18 AM, Thomas Hellstrom wrote:
On 11/28/2012 10: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 sta
On 11/29/2012 12:36 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 ttm_bo_w
On Thu, Nov 29, 2012 at 12:45:06PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> spinlock_t should always be used.
>
> LD drivers/gpu/drm/i915/built-in.o
> CHECK drivers/gpu/drm/i915/i915_drv.c
> CC [M] drivers/gpu/drm/i915/i915_drv.o
> CHECK drivers/gpu/drm/i
On Thu, Nov 29, 2012 at 9:33 PM, Thomas Hellstrom wrote:
> On 11/29/2012 01:52 PM, Marek Olšák wrote:
>>
>> On Thu, Nov 29, 2012 at 9:04 AM, Thomas Hellstrom
>> wrote:
>>>
>>> On 11/29/2012 03:15 AM, Marek Olšák wrote:
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson
wrote:
>
>>
From: "Luis R. Rodriguez"
Turns out a few drivers have strayed away from using the
spinlock_t typedef and decided to use struct spinlock
directly. This series converts these drivers to use
spinlock_t. Each change has been compile tested with
allmodconfig and sparse checked. Driver developers
may
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/gpu/drm/i915/built-in.o
CHECK drivers/gpu/drm/i915/i915_drv.c
CC [M] drivers/gpu/drm/i915/i915_drv.o
CHECK drivers/gpu/drm/i915/i915_dma.c
CC [M] drivers/gpu/drm/i915/i915_dma.o
CHECK drivers/gpu/drm/
On Thu, Nov 29, 2012 at 4:35 PM, wrote:
> So as a followup is 2 patch. The first one just stop trying to move
> object at each cs ioctl i believe it could be included in 3.7 as it
> improve performances (especialy with vram change from userspace).
>
> The second one implement a vram eviction poli
On Thu, Nov 29, 2012 at 8:57 PM, Marek Olšák wrote:
> On Thu, Nov 29, 2012 at 4:35 PM, wrote:
>> So as a followup is 2 patch. The first one just stop trying to move
>> object at each cs ioctl i believe it could be included in 3.7 as it
>> improve performances (especialy with vram change from use
2012/11/29 Daniel Vetter
> On Thu, Nov 29, 2012 at 1:11 PM, Inki Dae wrote:
> > - add sending AVI and AVI info frames.
> > . this adds some codes for composing AVI and AUI info frames
> > and send them every VSYNC for HDMI Certification.
>
> Imo we have a few too many avi infoframe impleme
On 11/29/2012 06:46 PM, Terje Bergström wrote:
> On 29.11.2012 12:01, Mark Zhang wrote:
>>
>> Just for curious, why "pb->mapped + 1K" is the end of a 4K pushbuffer?
>
> pb->mapped is u32 *, so compiler will take care of multiplying by
> sizeof(u32).
>
Ah, yes. Sorry, I must be insane at that tim
96 matches
Mail list logo
