From: Jerome Glisse <j.glisse@gmail.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "Christian Engelmayer" <cengelma@gmx.at>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Josh Triplett" <josh@joshtriplett.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Fabian Frederick" <fabf@skynet.be>,
Rashika <rashika.kheria@gmail.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 1/8] drm/<ttm-based-drivers>: Don't call drm_mmap
Date: Tue, 23 Sep 2014 17:57:56 -0400 [thread overview]
Message-ID: <20140923215756.GB13669@gmail.com> (raw)
In-Reply-To: <CANq1E4ThgF+oChBy8Y_oAnnzq0X=jdPFRJobZUGBuTcC9iDFVQ@mail.gmail.com>
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
next prev parent reply other threads:[~2014-09-23 21:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 13:46 [PATCH 0/8] More header rework Daniel Vetter
2014-09-23 13:46 ` [PATCH 1/8] drm/<ttm-based-drivers>: Don't call drm_mmap Daniel Vetter
2014-09-23 14:05 ` David Herrmann
2014-09-23 15:30 ` Christian König
2014-09-23 21:38 ` Jerome Glisse
2014-09-23 21:53 ` David Herrmann
2014-09-23 21:57 ` Jerome Glisse [this message]
2014-09-23 23:42 ` Ben Skeggs
2014-09-23 13:46 ` [PATCH 2/8] drm/gem: Don't call drm_mmap from drm_gem_mmap Daniel Vetter
2014-09-23 14:06 ` David Herrmann
2014-09-23 13:46 ` [PATCH 3/8] drm: move drm_mmap to <drm/drm_legacy.h> Daniel Vetter
2014-09-23 14:12 ` David Herrmann
2014-09-23 13:46 ` [PATCH 4/8] drm: Move drm_vm_open_locked into drm_internal.h Daniel Vetter
2014-09-23 14:15 ` David Herrmann
2014-09-23 14:21 ` Daniel Vetter
2014-09-23 13:46 ` [PATCH 5/8] drm: Move leftover ioctl declarations to drm_internal.h Daniel Vetter
2014-09-23 14:16 ` David Herrmann
2014-09-23 13:46 ` [PATCH 6/8] drm: Move internal debugfs functions " Daniel Vetter
2014-09-23 14:21 ` David Herrmann
2014-09-23 13:46 ` [PATCH 7/8] drm: Extract <drm/drm_gem.h> Daniel Vetter
2014-09-23 14:22 ` David Herrmann
2014-09-23 13:46 ` [PATCH 8/8] drm/doc: Fixup drm_irq kerneldoc includes Daniel Vetter
2014-09-23 14:22 ` David Herrmann
2014-09-23 14:25 ` Daniel Vetter
2014-09-23 14:24 ` [PATCH 0/8] More header rework David Herrmann
2014-09-23 15:11 ` Alex Deucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140923215756.GB13669@gmail.com \
--to=j.glisse@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=bskeggs@redhat.com \
--cc=cengelma@gmx.at \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabf@skynet.be \
--cc=josh@joshtriplett.org \
--cc=rashika.kheria@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).