On Fri, 2020-11-06 at 08:55 -0400, Jason Gunthorpe wrote:
> On Fri, Nov 06, 2020 at 11:27:59AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter
> > wrote:
> > > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard
> > > wrote:
> > > > On 11/5/20 4:49 AM, Jason Gunthorpe
On 2014-07-09 14:29, Maarten Lankhorst wrote:
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with
On 2014-07-09 14:29, Maarten Lankhorst wrote:
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with
On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object,
On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object,
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Jerome Glisse wrote:
> On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Keith Packard wrote:
>> > On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
>> >
>>
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Keith Packard wrote:
> On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
>
>
>> It might be possible to find schemes that work around this. One way
>> could possibly be to have a b
Keith Packard wrote:
On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
It might be possible to find schemes that work around this. One way
could possibly be to have a buffer mapping -and validate order for
shared buffers.
If mapping never blocks on anything other than
Keith Packard wrote:
On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
It might be possible to find schemes that work around this. One way
could possibly be to have a buffer mapping -and validate order for
shared buffers.
If mapping never blocks on anything other than
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
It might be possible to find schemes that work around this. One way
could possibly be to have a buffer mapping -and validate order
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
It might be possible to find schemes that work around
Eric Anholt wrote:
On Thu, 2007-04-26 at 16:55 +1000, Dave Airlie wrote:
Hi,
The patch is too big to fit on the list and I've no idea how we could
break it down further, it just happens to be a lot of new code..
Eric Anholt wrote:
On Thu, 2007-04-26 at 16:55 +1000, Dave Airlie wrote:
Hi,
The patch is too big to fit on the list and I've no idea how we could
break it down further, it just happens to be a lot of new code..
Dave Airlie wrote:
Most likely in doxygen as that is what Mesa uses and the intersection
of developers is higher in that area, I'll take it as a task to try
and kerneldoc the drm at some stage..
- what's with the /proc interface? Don't add new proc code for
non-process related things.
Dave Airlie wrote:
Most likely in doxygen as that is what Mesa uses and the intersection
of developers is higher in that area, I'll take it as a task to try
and kerneldoc the drm at some stage..
- what's with the /proc interface? Don't add new proc code for
non-process related things.
Dave Jones wrote:
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
> Dave Jones wrote:
> > On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> > > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > &
Dave Jones wrote:
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > Eric,
> > Sorry for the breakage. Can you try the attached patch and see if it
> > fixes the problem.
> >
> > /Thomas
>
> Thomas,
Dave Jones wrote:
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
Eric,
Sorry for the breakage. Can you try the attached patch and see if it
fixes the problem.
/Thomas
Thomas,
Thanks!
Dave Jones wrote:
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
Dave Jones wrote:
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
Eric,
Sorry for the breakage. Can you try
Eric Buddington wrote:
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
What AGP chipset do you have? it looks like it might be caused by the
AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI
Eric Buddington wrote:
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
What AGP chipset do you have? it looks like it might be caused by the
AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI
Dave Jones wrote:
On Sat, Jan 27, 2007 at 10:20:18AM +0100, Thomas Hellström wrote:
> Hi!
>
> Does anybody have a strong opinion against adding support for
> i386 Page Attribute Tables?
It pops up about once a year, everyone agrees it'd be a good idea,
and then nothing happens
Dave Jones wrote:
On Sat, Jan 27, 2007 at 10:20:18AM +0100, Thomas Hellström wrote:
Hi!
Does anybody have a strong opinion against adding support for
i386 Page Attribute Tables?
It pops up about once a year, everyone agrees it'd be a good idea,
and then nothing happens. Last year, I
system boot.
Where is the best place to do this?
/Thomas Hellström
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
system boot.
Where is the best place to do this?
/Thomas Hellström
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
Dave Airlie wrote:
>>
>>
>
> Don't know. But I bet someone on the Cc does...
>
Tilman,
Thanks for reporting.
Can you try the attached patch to see if that fixes the problem.
Hi Thomas,
This also fixes X starting on old i810/5 hardware, I had noticed it
broken but hadn't had time to
Dave Airlie wrote:
Don't know. But I bet someone on the Cc does...
Tilman,
Thanks for reporting.
Can you try the attached patch to see if that fixes the problem.
Hi Thomas,
This also fixes X starting on old i810/5 hardware, I had noticed it
broken but hadn't had time to investigate it,
haring enabled
<6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Please let me know if you need more information.
Don't know. But I bet someone on the Cc does...
Tilman,
Thanks for reporting.
Can you try the att
to see if that fixes the problem.
Regards,
Thomas Hellström
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index 91c1f36..6ef0960 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -190,6 +190,7 @@ struct agp_memory *agp_create_memory(int
return
Nick Piggin wrote:
On Tue, Jan 09, 2007 at 04:02:08PM +0100, Thomas Hellström wrote:
Nick,
We're working to slowly get the new DRM memory manager into the
mainstream kernel.
This means we have a need for the page fault handler patch you wrote
some time ago.
I guess we could take
Nick Piggin wrote:
On Tue, Jan 09, 2007 at 04:02:08PM +0100, Thomas Hellström wrote:
Nick,
We're working to slowly get the new DRM memory manager into the
mainstream kernel.
This means we have a need for the page fault handler patch you wrote
some time ago.
I guess we could take
Nick,
We're working to slowly get the new DRM memory manager into the
mainstream kernel.
This means we have a need for the page fault handler patch you wrote
some time ago.
I guess we could take the no_pfn() route, but that would need a check
for racing
unmap_mapping_range(), and other
Arjan van de Ven wrote:
A short recap why I belive the kmalloc / vmalloc construct is necessary:
0) The current code uses vmalloc only.
1) The allocated area ranges from 4 bytes possibly up to 512 kB, depending on
on the size of the AGP buffer allocated.
2) Large buffers are very few. Small
Arjan van de Ven wrote:
A short recap why I belive the kmalloc / vmalloc construct is necessary:
0) The current code uses vmalloc only.
1) The allocated area ranges from 4 bytes possibly up to 512 kB, depending on
on the size of the AGP buffer allocated.
2) Large buffers are very few. Small
Nick,
We're working to slowly get the new DRM memory manager into the
mainstream kernel.
This means we have a need for the page fault handler patch you wrote
some time ago.
I guess we could take the no_pfn() route, but that would need a check
for racing
unmap_mapping_range(), and other
Arjan van de Ven wrote:
On Tue, 2006-12-19 at 13:47 +0100, Thomas Hellström wrote:
Arjan van de Ven wrote:
A short background:
The current code uses vmalloc only. The potential use of kmalloc was
introduced
to save memory and cpu-speed.
All agp drivers expect to see a single memory
Arjan van de Ven wrote:
A short background:
The current code uses vmalloc only. The potential use of kmalloc was
introduced
to save memory and cpu-speed.
All agp drivers expect to see a single memory chunk, so I'm not sure we
want to have an array of pages. That may require rewriting a lot
Arjan van de Ven wrote:
On Sat, 2006-12-09 at 00:05 +0100, Thomas Hellström wrote:
On Fri, 2006-12-08 at 19:24 +0100, Thomas Hellström wrote:
+ }
+
+ if (alloc_size <= PAGE_SIZE) {
+ new->memory = kmalloc(alloc_size, GFP_KERNEL);
+ }
+ i
Arjan van de Ven wrote:
On Sat, 2006-12-09 at 00:05 +0100, Thomas Hellström wrote:
On Fri, 2006-12-08 at 19:24 +0100, Thomas Hellström wrote:
+ }
+
+ if (alloc_size = PAGE_SIZE) {
+ new-memory = kmalloc(alloc_size, GFP_KERNEL);
+ }
+ if (new
Arjan van de Ven wrote:
A short background:
The current code uses vmalloc only. The potential use of kmalloc was
introduced
to save memory and cpu-speed.
All agp drivers expect to see a single memory chunk, so I'm not sure we
want to have an array of pages. That may require rewriting a lot
Arjan van de Ven wrote:
On Tue, 2006-12-19 at 13:47 +0100, Thomas Hellström wrote:
Arjan van de Ven wrote:
A short background:
The current code uses vmalloc only. The potential use of kmalloc was
introduced
to save memory and cpu-speed.
All agp drivers expect to see a single memory
> On Fri, 2006-12-08 at 19:24 +0100, Thomas Hellström wrote:
>>
>> + }
>> +
>> + if (alloc_size <= PAGE_SIZE) {
>> + new->memory = kmalloc(alloc_size, GFP_KERNEL);
>> + }
>> + if (new->memory == NULL) {
>> + new->memory = vmalloc(alloc_size);
>
davej's agpgart.git
/Thomas Hellström
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index 7a6107f..75557de 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -1076,8 +1076,8 @@ int agp_generic_insert_memory(struct agp
for (i = 0, j = pg_start; i
che- and tlb flushing when needed.
It's not possible to request these types from user space using agpgart
ioctls.
The intel driver also gets a new memory type for pages that can be bound
cached to the intel GTT.
Patch against davej's agpgart.git
/Thomas Hellström
diff --git a/drivers/char/
- and tlb flushing when needed.
It's not possible to request these types from user space using agpgart
ioctls.
The intel driver also gets a new memory type for pages that can be bound
cached to the intel GTT.
Patch against davej's agpgart.git
/Thomas Hellström
diff --git a/drivers/char/agp
davej's agpgart.git
/Thomas Hellström
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index 7a6107f..75557de 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -1076,8 +1076,8 @@ int agp_generic_insert_memory(struct agp
for (i = 0, j = pg_start; i
On Fri, 2006-12-08 at 19:24 +0100, Thomas Hellström wrote:
+ }
+
+ if (alloc_size = PAGE_SIZE) {
+ new-memory = kmalloc(alloc_size, GFP_KERNEL);
+ }
+ if (new-memory == NULL) {
+ new-memory = vmalloc(alloc_size);
this bit is more or
47 matches
Mail list logo
