[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

2016-10-14 Thread Michał Winiarski
We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

2016-10-13 Thread Michał Winiarski
We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

2016-10-12 Thread Michał Winiarski
We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

2016-10-12 Thread Michał Winiarski
We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

2016-10-11 Thread Michał Winiarski
We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2: