On 04/08/2011 05:12 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 08, 2011 at 04:57:14PM +0200, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> Sorry for waiting so long to answer. Workload is quite heavy ATM.
>> Please see inline.
>>
> OK. Thank you for taking a look... some questions before
On 04/08/2011 04:57 PM, Thomas Hellstrom wrote:
> Konrad,
>
> Sorry for waiting so long to answer. Workload is quite heavy ATM.
> Please see inline.
>
>
> On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote:
I can start this next week if you guys are comfortable with this idea.
>>> K
Konrad,
Sorry for waiting so long to answer. Workload is quite heavy ATM.
Please see inline.
On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote:
>>> I can start this next week if you guys are comfortable with this idea.
>>>
>>>
>>>
>> Konrad,
>>
>> 1) A couple of questions first. Where
On Fri, Apr 08, 2011 at 04:57:14PM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> Sorry for waiting so long to answer. Workload is quite heavy ATM.
> Please see inline.
OK. Thank you for taking a look... some questions before you
depart on vacation.
> > 1). Get in the patch that passed in 'struct
On 04/08/2011 05:12 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Apr 08, 2011 at 04:57:14PM +0200, Thomas Hellstrom wrote:
Konrad,
Sorry for waiting so long to answer. Workload is quite heavy ATM.
Please see inline.
OK. Thank you for taking a look... some questions before you
depart on v
On Fri, Apr 08, 2011 at 04:57:14PM +0200, Thomas Hellstrom wrote:
> Konrad,
>
> Sorry for waiting so long to answer. Workload is quite heavy ATM.
> Please see inline.
OK. Thank you for taking a look... some questions before you
depart on vacation.
> > 1). Get in the patch that passed in 'struct
On 04/08/2011 04:57 PM, Thomas Hellstrom wrote:
Konrad,
Sorry for waiting so long to answer. Workload is quite heavy ATM.
Please see inline.
On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote:
I can start this next week if you guys are comfortable with this idea.
Konrad,
1) A couple of q
Konrad,
Sorry for waiting so long to answer. Workload is quite heavy ATM.
Please see inline.
On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote:
I can start this next week if you guys are comfortable with this idea.
Konrad,
1) A couple of questions first. Where are the memory pool
> >I can start this next week if you guys are comfortable with this idea.
> >
> >
>
> Konrad,
>
> 1) A couple of questions first. Where are the memory pools going to
> end up in this design. Could you draft an API? How is page
> accounting going to be taken care of? How do we differentiate
> betw
> >I can start this next week if you guys are comfortable with this idea.
> >
> >
>
> Konrad,
>
> 1) A couple of questions first. Where are the memory pools going to
> end up in this design. Could you draft an API? How is page
> accounting going to be taken care of? How do we differentiate
> betw
On 03/24/2011 05:21 PM, Konrad Rzeszutek Wilk wrote:
>>> When a page in the TTM pool is being moved back and forth and also changes
>>> the caching model, what happens on the free part? Is the original caching
>>> state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
>>> to an
On 03/24/2011 05:21 PM, Konrad Rzeszutek Wilk wrote:
When a page in the TTM pool is being moved back and forth and also changes
the caching model, what happens on the free part? Is the original caching
state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
to another pool for
> > When a page in the TTM pool is being moved back and forth and also changes
> > the caching model, what happens on the free part? Is the original caching
> > state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
> > to another pool for another radeon device. I also do some
On Thu, Mar 24, 2011 at 10:25 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
>> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
>> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
>> >>On 03/23/2011 01:51 PM, Konrad Rzesz
On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> >>On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >I was thinking about this a bit after I found
> > When a page in the TTM pool is being moved back and forth and also changes
> > the caching model, what happens on the free part? Is the original caching
> > state put back on it? Say I allocated a DMA32 page (GFP_DMA32), and move it
> > to another pool for another radeon device. I also do some
On Thu, Mar 24, 2011 at 10:25 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
>> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
>> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
>> >>On 03/23/2011 01:51 PM, Konrad Rzesz
On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
>
>> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
>>
> I was thinking about this a bit after I found that the PowerPC requires
> the 'struct dev'. But I
On Thu, Mar 24, 2011 at 08:52:20AM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> >>On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >I was thinking about this a bit after I found
On 03/23/2011 03:52 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
I was thinking about this a bit after I found that the PowerPC requires
the 'struct dev'. But I got a question fi
On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
>>> I was thinking about this a bit after I found that the PowerPC requires
>>> the 'struct dev'. But I got a question first, what do you with pages
>>> that were allocated to a device that can do 64-bit DMA and then
>>> move it to a device than
On Wed, Mar 23, 2011 at 8:51 AM, Konrad Rzeszutek Wilk
wrote:
>> >I was thinking about this a bit after I found that the PowerPC requires
>> >the 'struct dev'. But I got a question first, what do you with pages
>> >that were allocated to a device that can do 64-bit DMA and then
>> >move it to a de
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do you with pages
> >>>that were allocated to
On Wed, Mar 23, 2011 at 8:51 AM, Konrad Rzeszutek Wilk
wrote:
>> >I was thinking about this a bit after I found that the PowerPC requires
>> >the 'struct dev'. But I got a question first, what do you with pages
>> >that were allocated to a device that can do 64-bit DMA and then
>> >move it to a de
On 03/22/2011 03:31 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
>
>> Hi, Konrad,
>>
>> Is passing a struct device to the DMA api really *strictly* necessary?
>>
> Soo.. it seems it is on PowerPC, which I sadly didn't check for, does
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set th
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do you with pages
> >>>that were allocated to
On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
I was thinking about this a bit after I found that the PowerPC requires
the 'struct dev'. But I got a question first, what do you with pages
that were allocated to a device that can do 64-bit DMA and then
move it to a device than can 32-bit DMA
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set th
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Is passing a struct device to the DMA api really *strictly* necessary?
>
Yes.
> I'd like to avoid that at all cost, since we don't want pages that are
> backing buffer objects
> (coherent pages) to be associated with a specific
On 03/22/2011 03:31 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
Hi, Konrad,
Is passing a struct device to the DMA api really *strictly* necessary?
Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Is passing a struct device to the DMA api really *strictly* necessary?
>
Yes.
> I'd like to avoid that at all cost, since we don't want pages that are
> backing buffer objects
> (coherent pages) to be associated with a specific
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
>
> I'd like to avoid that at all cost, since we don't wa
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
>
> I'd like to avoid that at all cost, since we don't wa
Hi, Konrad,
Is passing a struct device to the DMA api really *strictly* necessary?
I'd like to avoid that at all cost, since we don't want pages that are
backing buffer objects
(coherent pages) to be associated with a specific device.
The reason for this is that we probably soon will want to mo
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
It is allowed. As said, it is a cleanup patch so it can be dropped.
>
> I'd like to avoid that at all cost, since we don't want pages that
>
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
>
> Is passing a struct device to the DMA api really *strictly* necessary?
It is allowed. As said, it is a cleanup patch so it can be dropped.
>
> I'd like to avoid that at all cost, since we don't want pages that
>
Hi, Konrad,
Is passing a struct device to the DMA api really *strictly* necessary?
I'd like to avoid that at all cost, since we don't want pages that are
backing buffer objects
(coherent pages) to be associated with a specific device.
The reason for this is that we probably soon will want to
These two patches are not strictly required but they do a bit of
cleanup and also fix a false reporting issue when the kernel is compiled
with CONFIG_DEBUG_DMA_API.
Essentially the patchset modifies 'struct ttm_tt' and 'struct ttm_bo_device'
to contain a pointer to 'struct device'. Passing of the
These two patches are not strictly required but they do a bit of
cleanup and also fix a false reporting issue when the kernel is compiled
with CONFIG_DEBUG_DMA_API.
Essentially the patchset modifies 'struct ttm_tt' and 'struct ttm_bo_device'
to contain a pointer to 'struct device'. Passing of the
40 matches
Mail list logo
