On Tue, Sep 23, 2014 at 11:53:53PM +0200, David Herrmann wrote:
Hi
On Tue, Sep 23, 2014 at 11:38 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Tue, Sep 23, 2014 at 03:46:47PM +0200, Daniel Vetter wrote:
Really, the legacy buffer api should be dead, especially for all these newfangled drivers. I suspect this is copypasta from the transitioning days, which probably originated in radeon.
Cc: David Airlie airlied@linux.ie Cc: Alex Deucher alexander.deucher@amd.com Cc: "Christian König" christian.koenig@amd.com Cc: David Herrmann dh.herrmann@gmail.com Cc: Rashika rashika.kheria@gmail.com Cc: Josh Triplett josh@joshtriplett.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: Fabian Frederick fabf@skynet.be Cc: Gerd Hoffmann kraxel@redhat.com Cc: Ben Skeggs bskeggs@redhat.com Cc: Alexandre Courbot acourbot@nvidia.com Cc: Maarten Lankhorst maarten.lankhorst@canonical.com Cc: Christian Engelmayer cengelma@gmx.at Signed-off-by: Daniel Vetter daniel.vetter@intel.com
I would say NAK as i am pretty sure this break radeon UMS code path. Of course if we have the go ahead to nuke radeon UMS i am more than happy.
radeon_drv.c says: driver_old.fops.mmap == drm_mmap;
..so I don't understand why that would break UMS? Do you use KMS mixed with UMS? radeon_mmap() is only used by radeon_driver_kms_fops, which is only used by kms_driver. UMS (which I understand as non-KMS in radeon case) should not be affected by this.
Oh this might be an heritage of old code in my mind when we had old user space running on top of KMS, more as a prototype stage and maybe also at one point the plan was to share the same mmap function so that old code could use new code cs ioctl.
So yeah this can be nuke sorry for the noise.
Thanks David