[Intel-gfx] [PATCH 1/3] drm/i915: Added a new 'I915_CPU_MAP_NOT_NEEDED' flag to gem_create ioctl.

[Gupta, Sourab]

On Mon, 2014-03-17 at 15:15 +0530, sourab gupta wrote:
> On Mon, 2014-03-10 at 22:07 +0000, 'Chris Wilson' wrote:
> > On Mon, Mar 10, 2014 at 04:12:23PM +0000, Gupta, Sourab wrote:
> > > 
> > > Hi Chris,
> > > 
> > > For the issue mentioned by you ( regarding botching up ioctls), we understand that this is related to the 
> > > compatibility between the older/newer versions of driver/userspace.
> > > In our old implementation, the 'pad' field was replaced with 'flags' in the ioctl structure. This would have 
> > > led to the erroneous behavior when the new userspace is communicating with old driver.
> > 
> > You missed the important point that there is no guarrantee that current
> > userspace is not stuffing garbage into the pad field. It is.
> > 
> > You have to go with a new ioctl. So you may as well design one that
> > tries to fulfil today's varied needs for a constructor.  For example,
> > here's one I prepared earlier,
> > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=create2&id=401fa740adcaf252d0149cdd63d5fdf5e3969907
> > -Chris
> > 
> 
> Hi Chris,
> 
> We went through this patch and this fulfills the requirements from the
> stolen mem perspective, and this looks like a replacement of the first
> patch we have submitted.
> This patch seems to be in your private branch. When do you plan to merge
> this patch with drm-intel branch?
> Have you also prepared the corresponding libdrm side patches? If so, can
> you share those also. Actually, the igt patch which we submitted earlier
> would also need to be modified according to the libdrm changes.
> 
> Also,
> When do you plan to merge the second and third patch in the series
> (truncation of stolen mem objs) as they seem to be fine to us.
> 
> Regards,
> Sourab
> 

Hi Chris,
We came across an earlier patch submitted by you regarding the ioctl for
user specified placement.
(http://lists.freedesktop.org/archives/intel-gfx/2013-July/029843.html)

As we understand, there were issues regarding the dma-buf support
regarding this patch.
Can you please tell us, whether it is planned to be taken up at a later
date (with/without dma-buf support).

Also, if the zeroing out of memory is required, we can provide an
additional patch on top of our earlier patches in order to clear the
memory gotten from stolen mem this way.

Regards,
Sourab