Displaying 5 results from an estimated 5 matches for "invividual".
Did you mean:
individual
2013 Nov 29
2
Fixing nouveau for >4k PAGE_SIZE
...> > Now, if those two assertions can be made always true:
> >
> > - Those two functions (map_sg and map_sg_table) never deal with the
> > "big" case.
> >
> > - An object is always mapped at a card address that is a multiple
> > of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries
> > when mapped)
> I think these two restrictions are reasonable to enforce, and we should do so.
>
> >
> > Then we can probably simplify the code significantly *and* go back to
> > handling PAGE_SIZE pages in the vmm-&g...
2013 Aug 11
2
Fixing nouveau for >4k PAGE_SIZE
.../base.c doesn't increment "pte" by the right amount.
Now, if those two assertions can be made always true:
- Those two functions (map_sg and map_sg_table) never deal with the
"big" case.
- An object is always mapped at a card address that is a multiple
of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries
when mapped)
Then we can probably simplify the code significantly *and* go back to
handling PAGE_SIZE pages in the vmm->map_sg() instead of breaking them
up a level above like I do.
> I don't like the duplicate definition, and the extra fo...
2013 Dec 11
0
Fixing nouveau for >4k PAGE_SIZE
...two assertions can be made always true:
>> >
>> > - Those two functions (map_sg and map_sg_table) never deal with the
>> > "big" case.
>> >
>> > - An object is always mapped at a card address that is a multiple
>> > of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries
>> > when mapped)
>
>> I think these two restrictions are reasonable to enforce, and we should do so.
>>
>> >
>> > Then we can probably simplify the code significantly *and* go back to
>> > handling PA...
2013 Aug 29
0
Fixing nouveau for >4k PAGE_SIZE
...te" by the right amount.
>
> Now, if those two assertions can be made always true:
>
> - Those two functions (map_sg and map_sg_table) never deal with the
> "big" case.
>
> - An object is always mapped at a card address that is a multiple
> of PAGE_SIZE (ie, invividual PAGE_SIZE pages don't cross pde boundaries
> when mapped)
I think these two restrictions are reasonable to enforce, and we should do so.
>
> Then we can probably simplify the code significantly *and* go back to
> handling PAGE_SIZE pages in the vmm->map_sg() instead of breaking...
2013 Aug 11
2
Fixing nouveau for >4k PAGE_SIZE
On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote:
> I think I found at least two cases where "12" was used where it should
> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This
> is only the tip of the iceberg, so this isn't a formal patch submission,
> but I would appreciate your thought as to whether the below is correct
> (and thus