On Die, 2011-03-22 at 10:54 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel D?nzer wrote:
> > On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> > > > On Fre, 2011-01-07 at 1
On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > >
> > > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > > with modif
On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel D?nzer wrote:
> On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> > > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > >
> > > > 1) The 'NULL'
On Die, 2011-03-22 at 10:54 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel Dänzer wrote:
> > On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> > > > On Fre, 2011-01-07 at 1
On Tue, Mar 22, 2011 at 02:13:19PM +0100, Michel Dänzer wrote:
> On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> > > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > >
> > > > 1) The 'NULL'
On Mon, 2011-03-21 at 19:18 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> > On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> > >
> > > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > > with modif
On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> >
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> > but
On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> >
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> > but
On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
>
> 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> but figured it would make first sense to get your guys input before heading
On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
>
> 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> but figured it would make first sense to get your guys input before heading
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
On Thu, Jan 27, 2011 at 10:28:45AM +0100, Thomas Hellstrom wrote:
> Konrad, Dave
>
> Given our previous discussion on the list, I believe these patches
> shouldn't introduce any regressions in the non-Xen case, however we
> should probably be prepared to back them out quickly if that turns
> out t
Konrad, Dave
Given our previous discussion on the list, I believe these patches
shouldn't introduce any regressions in the non-Xen case, however we
should probably be prepared to back them out quickly if that turns out
to be the case...
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszute
Konrad, Dave
Given our previous discussion on the list, I believe these patches
shouldn't introduce any regressions in the non-Xen case, however we
should probably be prepared to back them out quickly if that turns out
to be the case...
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszute
On Wed, Jan 12, 2011 at 10:19:39AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> > Hi, Konrad.
> >
> > This discussion has become a bit lenghty. I'll filter out the
> > sorted-out stuff, which leaves me with two remaining issues:
>
>
p
On Wed, Jan 12, 2011 at 10:19:39AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> > Hi, Konrad.
> >
> > This discussion has become a bit lenghty. I'll filter out the
> > sorted-out stuff, which leaves me with two remaining issues:
>
>
p
On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> Hi, Konrad.
>
> This discussion has become a bit lenghty. I'll filter out the
> sorted-out stuff, which leaves me with two remaining issues:
>
>
> On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote:
> >
> >So at the end we ha
Hi, Konrad.
This discussion has become a bit lenghty. I'll filter out the sorted-out
stuff, which leaves me with two remaining issues:
On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote:
>
> So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from
> 0->4GB. When you start allocati
On Wed, Jan 12, 2011 at 10:12:14AM +0100, Thomas Hellstrom wrote:
> Hi, Konrad.
>
> This discussion has become a bit lenghty. I'll filter out the
> sorted-out stuff, which leaves me with two remaining issues:
>
>
> On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote:
> >
> >So at the end we ha
Hi, Konrad.
This discussion has become a bit lenghty. I'll filter out the sorted-out
stuff, which leaves me with two remaining issues:
On 01/11/2011 04:55 PM, Konrad Rzeszutek Wilk wrote:
So at the end we have 16GB taken from 8GB->24GB, and 320MB taken from
0->4GB. When you start allocating
On Tue, Jan 11, 2011 at 1:28 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
>> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
>> wrote:
>> >> >> Another thing that I was thinking of is what happens if you have a
>> >> >> huge gart and all
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent memory. Could that
> >> >> potentially exhaus
On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
wrote:
>> >> Another thing that I was thinking of is what happens if you have a
>> >> huge gart and allocate a lot of coherent memory. Could that
>> >> potentially exhaust IOMMU resources?
>> >
>> >
>> >
>> > So the GART is in the PCI space
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
On Tue, Jan 11, 2011 at 1:28 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
>> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
>> wrote:
>> >> >> Another thing that I was thinking of is what happens if you have a
>> >> >> huge gart and all
On Tue, Jan 11, 2011 at 10:55 AM, Konrad Rzeszutek Wilk
wrote:
> . snip ..
>> >>>I think the error path would be the same in both cases?
>> >>Not really. The really dangerous situation is if TTM is allowed to
>> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
>> >Ok, since GFP
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
On Tue, Jan 11, 2011 at 01:12:57PM -0500, Alex Deucher wrote:
> On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
> wrote:
> >> >> Another thing that I was thinking of is what happens if you have a
> >> >> huge gart and allocate a lot of coherent memory. Could that
> >> >> potentially exhaus
On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk
wrote:
>> >> Another thing that I was thinking of is what happens if you have a
>> >> huge gart and allocate a lot of coherent memory. Could that
>> >> potentially exhaust IOMMU resources?
>> >
>> >
>> >
>> > So the GART is in the PCI space
> >> Another thing that I was thinking of is what happens if you have a
> >> huge gart and allocate a lot of coherent memory. Could that
> >> potentially exhaust IOMMU resources?
> >
> >
> >
> > So the GART is in the PCI space in one of the BARs of the device right?
> > (We are talking about the d
On Tue, Jan 11, 2011 at 10:55 AM, Konrad Rzeszutek Wilk
wrote:
> . snip ..
>> >>>I think the error path would be the same in both cases?
>> >>Not really. The really dangerous situation is if TTM is allowed to
>> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
>> >Ok, since GFP
. snip ..
> >>>I think the error path would be the same in both cases?
> >>Not really. The really dangerous situation is if TTM is allowed to
> >>exhaust all GFP_KERNEL memory. Then any application or kernel task
> >Ok, since GFP_KERNEL does not contain the GFP_DMA32 flag then
> >this should be OK?
On 01/10/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> . snip ..
>
2) What about accounting? In a *non-Xen* environment, will the
number of coherent pages be less than the number of DMA32 pages, or
will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
On 01/10/2011 04:21 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> Before looking further into the patch series, I need to make sure
>> I've completely understood the problem and why you've chosen this
>> solution: Please
Konrad,
Before looking further into the patch series, I need to make sure I've
completely understood the problem and why you've chosen this solution:
Please see inline.
On 01/07/2011 06:11 PM, Konrad Rzeszutek Wilk wrote:
> Attached is a set of patches that make it possible for drivers using TT
On 01/10/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
. snip ..
2) What about accounting? In a *non-Xen* environment, will the
number of coherent pages be less than the number of DMA32 pages, or
will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
The code in the IO
. snip ..
> >>2) What about accounting? In a *non-Xen* environment, will the
> >>number of coherent pages be less than the number of DMA32 pages, or
> >>will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
> >The code in the IOMMUs end up calling __get_free_pages, which ends up
> >i
On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
> Konrad,
>
> Before looking further into the patch series, I need to make sure
> I've completely understood the problem and why you've chosen this
> solution: Please see inline.
Of course.
.. snip ..
> >The problem above can be e
. snip ..
> >>2) What about accounting? In a *non-Xen* environment, will the
> >>number of coherent pages be less than the number of DMA32 pages, or
> >>will dma_alloc_coherent just translate into a alloc_page(GFP_DMA32)?
> >The code in the IOMMUs end up calling __get_free_pages, which ends up
> >i
On 01/10/2011 04:21 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
Konrad,
Before looking further into the patch series, I need to make sure
I've completely understood the problem and why you've chosen this
solution: Please see inline.
On Mon, Jan 10, 2011 at 03:25:55PM +0100, Thomas Hellstrom wrote:
> Konrad,
>
> Before looking further into the patch series, I need to make sure
> I've completely understood the problem and why you've chosen this
> solution: Please see inline.
Of course.
.. snip ..
> >The problem above can be e
On Fri, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> Attached is a set of patches that make it possible for drivers using TTM API
> (nouveau and radeon graphic drivers) to work under Xen. The explanation
> is a bit complex and I am not sure if I am explaining it that well..so if
> som
Konrad,
Before looking further into the patch series, I need to make sure I've
completely understood the problem and why you've chosen this solution:
Please see inline.
On 01/07/2011 06:11 PM, Konrad Rzeszutek Wilk wrote:
Attached is a set of patches that make it possible for drivers using T
Hi, Konrad!
Just back from vacation. I'll try to review this patch set in the
upcoming week!
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszutek Wilk wrote:
> Attached is a set of patches that make it possible for drivers using TTM API
> (nouveau and radeon graphic drivers) to work under X
Hi, Konrad!
Just back from vacation. I'll try to review this patch set in the
upcoming week!
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszutek Wilk wrote:
Attached is a set of patches that make it possible for drivers using TTM API
(nouveau and radeon graphic drivers) to work under Xe
On Fri, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote:
> Attached is a set of patches that make it possible for drivers using TTM API
> (nouveau and radeon graphic drivers) to work under Xen. The explanation
> is a bit complex and I am not sure if I am explaining it that well..so if
> som
Attached is a set of patches that make it possible for drivers using TTM API
(nouveau and radeon graphic drivers) to work under Xen. The explanation
is a bit complex and I am not sure if I am explaining it that well..so if
something is unclear please do ping me.
Changes since v1: [https://lkml.org
Attached is a set of patches that make it possible for drivers using TTM API
(nouveau and radeon graphic drivers) to work under Xen. The explanation
is a bit complex and I am not sure if I am explaining it that well..so if
something is unclear please do ping me.
Changes since v1: [https://lkml.org
48 matches
Mail list logo
